[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    Re: [cifs-protocol] [REG:119102421000015] MS-ADTS dirsync and extended-dn interactions
From:       Andrew Bartlett via cifs-protocol <cifs-protocol () lists ! samba ! org>
Date:       2019-10-24 2:28:45
Message-ID: 80ccfaa3f219f40d92361b3e560006d62d654dc9.camel () samba ! org
[Download RAW message or body]

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 <jeffm@microsoft.com> 
> Sent: Wednesday, October 23, 2019 8:13 PM
> To: Andrew Bartlett <abartlet@samba.org>; 
> cifs-protocol@lists.samba.org
> Cc: bjacke@samba.org; Stefan Metzmacher <metze@samba.org>; support <
> support@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.c \
> om%2Fglobalenglish&amp;data=02%7C01%7Cedgaro%40microsoft.com%7C0fc12a220333491d0eaa0 \
> 8d75816e61b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074727681835459&amp;sdata=v9ch40MkTuGBBz6pPX45p%2BYBkPhK0wb7GZwK370%2B%2F0I%3D&amp;reserved=0
>  | Extension 1138300 We value your feedback.  My manager is Jeremy
> Chapman (jeremyc), +1 (469) 775-2475
> 
> -----Original Message-----
> From: Andrew Bartlett <abartlet@samba.org>
> Sent: Wednesday, October 23, 2019 3:27 PM
> To: cifs-protocol@lists.samba.org
> Cc: Interoperability Documentation Help <dochelp@microsoft.com>; 
> bjacke@samba.org; Stefan Metzmacher <metze@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%2 \
Fshow_bug.cgi%3Fid%3D14153&amp;data=02%7C01%7Cedgaro%40microsoft.com%7C0fc12a220333491 \
d0eaa08d75816e61b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074727681835459&amp;sdata=hbFVuwbqdh5GuAor4inTRLw8g%2FZ620nVg%2BSIsWzIL%2FU%3D&amp;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&amp;data=02%7C01%7Cedgaro%40microsoft.com%7C0fc12a220333491d0eaa08d75816e61b%7C72f9 \
88bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074727681840437&amp;sdata=QskCzelB0mK5j5u40v3tF8fr9DNaqp7JvOXEBpg%2BDGk%3D&amp;reserved=0

> Authentication Developer, Samba Team         
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsamba.org&amp;data \
> =02%7C01%7Cedgaro%40microsoft.com%7C0fc12a220333491d0eaa08d75816e61b%7C72f988bf86f14 \
> 1af91ab2d7cd011db47%7C1%7C0%7C637074727681840437&amp;sdata=swARbMPGbAElOA6YLj2bG78JaXXEKUKeeb7VZtzV8oI%3D&amp;reserved=0
>  Samba Development and Support, Catalyst IT
> 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcatalyst.net.nz%2Fse \
rvices%2Fsamba&amp;data=02%7C01%7Cedgaro%40microsoft.com%7C0fc12a220333491d0eaa08d7581 \
6e61b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074727681840437&amp;sdata=HBt2IV9EDFcjbHpJeolMbsdcDEO4epG%2F42xhBeETpls%3D&amp;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


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic