G'Day, I'm sorry, I misunderstood metze's patch, it seems that these controls just stack correctly from a protocol perspective.
Internally Samba needed extended DN Details, but we just got it wrong in terms of what we returned to the client, when they asked for format 0 and we interally asked for format 1. https://gitlab.com/samba-team/samba/merge_requests/862 So there isn't anything to do here. Thanks for following up. I'll let you know if I have any questions coming from my review work on metze's patch, but for now you can close this. Sorry! Andrew Bartlett On Thu, 2019-10-24 at 00:52 +0000, Edgar Olougouna via cifs-protocol wrote: > Andrew, > Thanks for looking further into this and reaching out. Based on your > experimentation, does it mean that one control implies the other, > meaning it's only one control effectively? Or are you observing that > one supersedes the other? Is this a version specific or functional- > level specific behavior? > I'll review this and follow-up. > > Regards, > Edgar > > -----Original Message----- > From: Jeff McCashland <je...@microsoft.com> > Sent: Wednesday, October 23, 2019 8:13 PM > To: Andrew Bartlett <abart...@samba.org>; > cifs-protocol@lists.samba.org > Cc: bja...@samba.org; Stefan Metzmacher <me...@samba.org>; support < > supp...@mail.support.microsoft.com> > Subject: [REG:119102421000015] MS-ADTS dirsync and extended-dn > interactions > > [DocHelp to BCC, support on CC, SR ID on Subject] > > Hi Andrew, > > Thank you for your Active Directory question. We have created SR > 119102421000015 to track this issue. One of our engineers will > respond soon to assist. > > Best regards, > Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol > Open Specifications Team > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC- > 08:00) Pacific Time (US and Canada) Local country phone number found > here: > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=02%7C01%7Cedgaro%40microsoft.com%7C0fc12a220333491d0eaa08d75816e61b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074727681835459&sdata=v9ch40MkTuGBBz6pPX45p%2BYBkPhK0wb7GZwK370%2B%2F0I%3D&reserved=0 > | Extension 1138300 We value your feedback. My manager is Jeremy > Chapman (jeremyc), +1 (469) 775-2475 > > -----Original Message----- > From: Andrew Bartlett <abart...@samba.org> > Sent: Wednesday, October 23, 2019 3:27 PM > To: cifs-protocol@lists.samba.org > Cc: Interoperability Documentation Help <doch...@microsoft.com>; > bja...@samba.org; Stefan Metzmacher <me...@samba.org> > Subject: MS-ADTS dirsync and extended-dn interactions > > G'Day, > > Per a call with Edgar and Brian today. > > While looking at a Samba fix for our Samba AD DC being contacted by > Microsoft Azure, I notied that the interaction that is fixed by this > Samba bug isn't clearly documented: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.samba.org%2Fshow_bug.cgi%3Fid%3D14153&data=02%7C01%7Cedgaro%40microsoft.com%7C0fc12a220333491d0eaa08d75816e61b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074727681835459&sdata=hbFVuwbqdh5GuAor4inTRLw8g%2FZ620nVg%2BSIsWzIL%2FU%3D&reserved=0 > > That is, while MS-ATDS specified both of these controls and while > LDAP_SERVER_DIRSYNC_OID implies LDAP_SERVER_EXTENDED_DN_OID (not that > I coudl find that documented in a brief serch), the inteaction is not > ccalled out. > > That is, as I understand it from the patch, during dirsync if > LDAP_SERVER_EXTENDED_DN_OID is specified explicitly, then the > returned data format (0 - the default, or 1) comes from that control. > > It would be good if this was made clearer. > > Thanks! > > Andrew Bartlett > > -- > Andrew Bartlett > https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fsamba.org%2F~abartlet%2F&data=02%7C01%7Cedgaro%40microsoft.com%7C0fc12a220333491d0eaa08d75816e61b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074727681840437&sdata=QskCzelB0mK5j5u40v3tF8fr9DNaqp7JvOXEBpg%2BDGk%3D&reserved=0 > Authentication Developer, Samba Team > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsamba.org&data=02%7C01%7Cedgaro%40microsoft.com%7C0fc12a220333491d0eaa08d75816e61b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074727681840437&sdata=swARbMPGbAElOA6YLj2bG78JaXXEKUKeeb7VZtzV8oI%3D&reserved=0 > Samba Development and Support, Catalyst IT > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcatalyst.net.nz%2Fservices%2Fsamba&data=02%7C01%7Cedgaro%40microsoft.com%7C0fc12a220333491d0eaa08d75816e61b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074727681840437&sdata=HBt2IV9EDFcjbHpJeolMbsdcDEO4epG%2F42xhBeETpls%3D&reserved=0 > > > > > > > _______________________________________________ > cifs-protocol mailing list > cifs-protocol@lists.samba.org > https://lists.samba.org/mailman/listinfo/cifs-protocol -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Development and Support, Catalyst IT https://catalyst.net.nz/services/samba _______________________________________________ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol