[cifs-protocol] MS-ADTS: DC handling of modification to msDS-AdditionalDnsHostName [120061624003212]

Obaid Farooqi obaidf at microsoft.com
Mon Jun 22 18:28:48 UTC 2020


Hi Isaac:
Is there an easy wasy to reproduce this? It appears that joing a computer to a domain will trigger this but I am not sure if the creation of a computer object always results in creation of this attribute.

Regards,
Obaid Farooqi
Escalatiion Engineer | Microsoft

-----Original Message-----
From: Obaid Farooqi 
Sent: Tuesday, June 16, 2020 11:10 AM
To: Isaac Boukris <iboukris at gmail.com>; Stefan Metzmacher <metze at samba.org>; Andreas Schneider <asn at samba.org>; cifs-protocol at lists.samba.org
Cc: support <support at mail.support.microsoft.com>
Subject: RE: MS-ADTS: DC handling of modification to msDS-AdditionalDnsHostName [120061624003212]

Hi Isaac:
Thanks for contacting Microsoft. I have created a case to track this issue. A member of the open specifications team will be in touch soon.

Regards,
Obaid Farooqi
Escalatiion Engineer | Microsoft

-----Original Message-----
From: Isaac Boukris <iboukris at gmail.com> 
Sent: Tuesday, June 16, 2020 5:45 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>; Stefan Metzmacher <metze at samba.org>; Andreas Schneider <asn at samba.org>; cifs-protocol at lists.samba.org
Subject: [EXTERNAL] MS-ADTS: DC handling of modification to msDS-AdditionalDnsHostName

Hello dochelp,

I noticed that each time an msDS-AdditionalDnsHostName attribute is added to a computer object (netdom/adsi/ldapmodify), Windows DC also adds another short entry (up to the first dot if any) with a binary '\0$' suffix.
This causes ldap_get_values() to fail parsing it as a string, and
ldap_get_values_len() needs to be used instead.

Looking in the docs I couldn't find any mention for this handling, and wonder if the '\0$' is in purpose or a bug, and how it should be handled by implementations.

Thank you


More information about the cifs-protocol mailing list