[cifs-protocol] [EXTERNAL] Re: dNSProperty parsing of DSPROPERTY_ZONE_NS_SERVERS_DA in particular [120040622000005]
Andrew Bartlett
abartlet at samba.org
Wed Apr 22 22:25:29 UTC 2020
Thanks, so by reject do you mean ignore (pretend that value was never
there)?
(We got into the muddle because we started to hard reject the records,
and failed the operation).
Thanks,
Andrew Bartlett
On Wed, 2020-04-22 at 22:18 +0000, Obaid Farooqi wrote:
> Hi Andrew:
> We are almost there.
> The research is just waiting some official confirmation but code
> browsing suggest that we do not perform any validation when data is
> written to AD. But at the time when DNS reads it, it will reject such
> kind of records.
>
> I'll update you if there is a change in this.
>
> Regards,
> Obaid Farooqi
> Escalatiion Engineer | Microsoft
>
> -----Original Message-----
> From: Andrew Bartlett <abartlet at samba.org>
> Sent: Wednesday, April 22, 2020 4:59 PM
> To: Obaid Farooqi <obaidf at microsoft.com>; cifs-protocol mailing list
> <cifs-protocol at lists.samba.org>
> Cc: support <support at mail.support.microsoft.com>
> Subject: [EXTERNAL] Re: [cifs-protocol] dNSProperty parsing of
> DSPROPERTY_ZONE_NS_SERVERS_DA in particular [120040622000005]
>
> G'Day Obiad,
>
> Any news on this one?
>
> Thanks,
>
> Andrew Bartlett
>
> On Mon, 2020-04-06 at 01:44 +0000, Obaid Farooqi via cifs-protocol
> wrote:
> > Hi Andrew:
> > 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
> > Escalation Engineer | Microsoft
> >
> > -----Original Message-----
> > From: Andrew Bartlett <abartlet at samba.org>
> > Sent: Sunday, April 5, 2020 6:44 PM
> > To: Interoperability Documentation Help <dochelp at microsoft.com>;
> > cifs-protocol mailing list <cifs-protocol at lists.samba.org>
> > Subject: [EXTERNAL] dNSProperty parsing of
> > DSPROPERTY_ZONE_NS_SERVERS_DA in particular
> >
> > G'Day Dochelp,
> >
> > I'm hoping for a little help with interoperability here. The
> > situation is a Samba AD Domain that has also had a Windows AD DC
> > in
> > it, so some records were not created by Samba, like this records
> > in
> > the DNS partition.
> >
> > In the
> >
> > DC=_msdcs.X.Y,CN=MicrosoftDNS,DC=ForestDnsZones,DC=X,DC=Y
> >
> > record, there is an attribute:
> >
> > dNSProperty:: AAAAAAAAAAAAAAAAAQAAAJIAAAAAAAAA
> >
> > 000000 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
> > 00 >................<
> > 000010 92 00 00 00 00 00 00 00 >........<
> > 000018
> >
> > We, until samba 4.12, would parse this as:
> >
> > pull returned Success
> > dnsp_DnsProperty: struct dnsp_DnsProperty
> > wDataLength : 0x00000000 (0)
> > namelength : 0x00000000 (0)
> > flag : 0x00000000 (0)
> > version : 0x00000001 (1)
> > id : DSPROPERTY_ZONE_NS_SERVERS_DA
> > (146)
> > data : union dnsPropertyData(case 0)
> > name : 0x00000000 (0)
> > dump OK
> >
> > However, the wDataLength is 0. There is not anything in [MS-DNSP]
> > 2.3.2.1 dnsProperty to describe any special behaviour for when the
> > id
> > suggests that there is a value, but wDataLength is 0.
> >
> >
>
>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-dnsp%2F445c7843-e4a1-4222-8c0f-630c230a4c80&data=02%7C01%7Cobaidf%40microsoft.com%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=YUcS83iOfEhA%2BdDtvh4udt%2FHSS9HHnE1aCdP6yN85cM%3D&reserved=0
> >
> > We now fail to parse it, because we expect an entry with id
> > DSPROPERTY_ZONE_NS_SERVERS_DA to therefore have a valid
> > DNS_ADDR_ARRAY
> > (section 2.2.3.2.3).
> >
> > As context (mostly for my fellow team members), we changed it in
> > our
> > commit
> >
>
>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.samba.org%2F%3Fp%3Dsamba.git%3Ba%3Dcommit%3Bh%3Dfee5c6a4247aeac71318186bbff7708d25de5912&data=02%7C01%7Cobaidf%40microsoft.com%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=E1zkAtFDG9ONCp8CIKUzNjiZ%2FXVXTfB%2B37v1UyOR9Bs%3D&reserved=0
> > because of bug
> >
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> > illa.samba.org%2Fshow_bug.cgi%3Fid%3D14206&data=02%7C01%7Cobaid
> > f%4
> > 0microsoft.com%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141a
> > f91
> > ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=3hTeDUXXBaCPK
> > EA0
> > aefJ%2Bswd4XDRvrvgflV3iKEM5%2F4%3D&reserved=0
> > which was due to the artificial environment of the fuzzer.
> >
> > Can you clarify how this should be interpreted, so we can fix this
> > properly?
> >
> > Thanks!
> >
> > Andrew Bartlett
> >
>
> --
> Andrew Bartlett
> https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fsamba.org%2F~abartlet%2F&data=02%7C01%7Cobaidf%40microsoft.com%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=AzUdz%2FQOb4tLOUebkVKXL3eJ%2BsyJOAEbti%2Fav%2Fehk7A%3D&reserved=0
> Authentication Developer, Samba Team
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsamba.org%2F&data=02%7C01%7Cobaidf%40microsoft.com%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=KdvIxvqdb86QnnGnQuVSnFSl2stf1OwMsoC9PALuxmg%3D&reserved=0
> Samba Developer, Catalyst IT
>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcatalyst.net.nz%2Fservices%2Fsamba&data=02%7C01%7Cobaidf%40microsoft.com%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=yyRKLHbzoGejyC0C1ZLBjLFYdgf0G9XQkK6NglXXuzs%3D&reserved=0
>
>
>
--
Andrew Bartlett https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Developer, Catalyst IT
https://catalyst.net.nz/services/samba
More information about the cifs-protocol
mailing list