[cifs-protocol] [REG:118040517948537] MS-ADTS: msDS-ResultantPSO and DOMAIN_USER_RID_KRBTGT discrepancy

Thu Apr 26 23:02:16 UTC 2018

Good to know. Thanks, Obaid.

On 27/04/18 07:28, Obaid Farooqi wrote:
> Hi Tim:
> I got some additional detail on this prom product group, as follows:
> "
> This is not a security issue. The password for krbtgt is not human generated and any PSO applied on it will be ignored.
> "
> The recommendation is to follow the document instead of observed Windows behavior. This bug will be fixed in a future release of Windows and document will be updated to mention which version of Windows ignore this rule.
>
> Please let me know if it does not answer your question.
>
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
>
> Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at ramagane at Microsoft dot com
>
> -----Original Message-----
> From: Tim Beale <timbeale at catalyst.net.nz> 
> Sent: Wednesday, April 25, 2018 3:50 PM
> To: Obaid Farooqi <obaidf at microsoft.com>
> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at microsoft.com>
> Subject: Re: [REG:118040517948537] MS-ADTS: msDS-ResultantPSO and DOMAIN_USER_RID_KRBTGT discrepancy
>
> Hi Obaid,
>
> Thank you for clarifying the expected behaviour. That makes sense.
>
> Cheers,
> Tim
>
> On 25/04/18 04:54, Obaid Farooqi wrote:
>> Hi Tim:
>> The code actually intends to not return msDS-ResultantPSO when RID is equal to that of krbtgt but due to a bug, the comparison fails and instead of nothing, the msDS-ResultantPSO is returned. I tested against WS2012R2. The code is identical from Vista (WS2008) till Ws2012R2. I have not checked against WS2016 yet. 
>>
>> I have filed a bug against MS-ADTS to fix this issue.
>>
>>
>> Regards,
>> Obaid Farooqi
>> Escalation Engineer | Microsoft
>>
>> Exceeding your expectations is my highest priority.  If you would like 
>> to provide feedback on your case you may contact my manager at 
>> ramagane at Microsoft dot com
>>
>> -----Original Message-----
>> From: Tim Beale <timbeale at catalyst.net.nz>
>> Sent: Monday, April 9, 2018 12:12 AM
>> To: Obaid Farooqi <obaidf at microsoft.com>
>> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email 
>> <casemail at microsoft.com>
>> Subject: Re: [REG:118040517948537] MS-ADTS: msDS-ResultantPSO and 
>> DOMAIN_USER_RID_KRBTGT discrepancy
>>
>> Hi Obaid,
>>
>> You can reproduce the problem by doing the following:
>>
>> - Create a new msDS-PasswordSettings object. E.g.
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs
>> .technet.microsoft.com%2Fcanitpro%2F2013%2F05%2F29%2Fstep-by-step-enab
>> ling-and-using-fine-grained-password-policies-in-ad%2F&data=02%7C01%7C
>> obaidf%40microsoft.com%7C9e0e2771473540762c9508d59dd85fb4%7C72f988bf86
>> f141af91ab2d7cd011db47%7C1%7C0%7C636588475007318631&sdata=iztmo%2BfkcS
>> ggbJe%2FxTDmIA4ZW75noVaDRW%2FfRbvxA4k%3D&reserved=0
>> or a more out-dated approach using ADSI Edit (which I think I used
>> originally)
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs
>> .technet.microsoft.com%2Fseanearp%2F2007%2F10%2F06%2Fwindows-server-20
>> 08-fine-grained-password-policy-walkthrough%2F&data=02%7C01%7Cobaidf%4
>> 0microsoft.com%7C9e0e2771473540762c9508d59dd85fb4%7C72f988bf86f141af91
>> ab2d7cd011db47%7C1%7C0%7C636588475007318631&sdata=3%2FkmbCFEDopECsTsyK
>> vtgV%2FtRNX9UBru7G5QJqbJ57c%3D&reserved=0
>> - Apply the PSO to the krbtgt user. I did this by opening ADSI Edit, 
>> right-clicking on the PSO created in the previous step, select 
>> 'Properties', then edit the msDS-PSOAppliesTo attribute. I used the 
>> 'Add DN' option and just pasted in the DN of the krbtgt user (then 
>> click 'OK', and 'Apply').
>> - Check the Resultant PSO. i.e. In ADSI Edit, right-click on the 
>> krbtgt user, select 'Properties', then look for the msDS-ResultantPSO attribute.
>>
>> I've actually been testing this as part of Samba development by using 
>> a python test script that connects to the Windows DC over LDAP and 
>> does the above steps as LDIF operations. So you can probably reproduce 
>> the first 2 steps just by applying an LDIF (tentative example follows, 
>> but I haven't tried using exactly this approach myself).
>>
>> dn: CN=test-PSO,CN=Password Settings 
>> Container,CN=System,DC=<your-domain>
>> changetype: add
>> objectClass: msDS-PasswordSettings
>> msDS-PasswordSettingsPrecedence: 2
>> msDS-PasswordReversibleEncryptionEnabled: FALSE
>> msDS-PasswordHistoryLength: 10
>> msDS-PasswordComplexityEnabled: TRUE
>> msDS-MinimumPasswordLength: 10
>> msDS-MinimumPasswordAge: 0
>> msDS-MaximumPasswordAge: -25920000000000
>> msDS-LockoutThreshold: 0
>> msDS-LockoutObservationWindow: -50000000
>> msDS-LockoutDuration: -50000000
>> msDS-PSOAppliesTo: CN=krbtgt,CN=Users,DC=<your-domain>
>>
>> Cheers,
>> Tim
>>
>> On 07/04/18 08:27, Obaid Farooqi wrote:
>>> Hi Tim:
>>> Can you please let me know the step you took to add this object and applied to krbtgt?
>>>
>>> Regards,
>>> Obaid Farooqi
>>> Escalation Engineer | Microsoft
>>>
>>> Exceeding your expectations is my highest priority.  If you would 
>>> like to provide feedback on your case you may contact my manager at 
>>> ramagane at Microsoft dot com
>>>
>>> -----Original Message-----
>>> From: Obaid Farooqi
>>> Sent: Friday, April 6, 2018 12:48 PM
>>> To: 'Tim Beale' <timbeale at catalyst.net.nz>
>>> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email 
>>> <casemail at microsoft.com>
>>> Subject: RE: [REG:118040517948537] MS-ADTS: msDS-ResultantPSO and 
>>> DOMAIN_USER_RID_KRBTGT discrepancy
>>>
>>> Hi Tim:
>>> I'll help you with this issue and will be in touch as soon as I have an answer.
>>>
>>> Regards,
>>> Obaid Farooqi
>>> Escalation Engineer | Microsoft
>>>
>>> Exceeding your expectations is my highest priority.  If you would 
>>> like to provide feedback on your case you may contact my manager at 
>>> ramagane at Microsoft dot com
>>>
>>> -----Original Message-----
>>> From: Obaid Farooqi
>>> Sent: Friday, April 6, 2018 12:47 PM
>>> To: "'Tim Beale'" <timbeale at catalyst.net.nz>
>>> Cc: "cifs-protocol at lists.samba.org" <cifs-protocol at lists.samba.org>; 
>>> "MSSolve Case Email" <casemail at microsoft.com>
>>> Subject: [REG:118040517948537] MS-ADTS: msDS-ResultantPSO and 
>>> DOMAIN_USER_RID_KRBTGT discrepancy
>>>
>>> Hello Tim
>>>
>>> We have created a case; 118040517948537, to track your inquiry and an Escalation Engineer will contact you to assist further.
>>>
>>> Best Regards,
>>> Tarun Chopra | Sr. Escalation Engineer Open Specifications Support 
>>> Team Work +1-425-705-5042 Email  tarun.chopra at microsoft.com 
>>> Monday-Friday 9:00a-6:00p Pacific Timezone
>>>
>>> -----Original Message-----
>>> From: Tim Beale <timbeale at catalyst.net.nz>
>>> Sent: Thursday, April 5, 2018 2:00 PM
>>> To: Interoperability Documentation Help <dochelp at microsoft.com>; 
>>> cifs-protocol at lists.samba.org
>>> Subject: MS-ADTS: msDS-ResultantPSO and DOMAIN_USER_RID_KRBTGT 
>>> discrepancy
>>>
>>> Hi,
>>>
>>> I'm looking into the behaviour of msDS-ResultantPSO and found a discrepancy between the specification and the actual behaviour.
>>>
>>> In MS-ADTS, section 3.1.1.4.5.36 msDS-ResultantPSO [1], it says the
>>> following: 
>>>
>>>   If the RID in U!objectSid is equal to DOMAIN_USER_RID_KRBTGT, then there is no value in this attribute. 
>>>
>>> I tried adding a PSO object and applying it to the krbtgt user on a Windows 2012R2 VM. Based on the spec, I would expect no msDS-ResultantPSO to be returned for the krbtgt user. However, I do see one returned, e.g.
>>>
>>> # record 1
>>> dn: 
>>> CN=krbtgt,CN=Users,DC=WINDOWS2012R2,DC=WIN,DC=TIM,DC=WGTN,DC=CAT-IT,D
>>> C=
>>> CO,DC=NZ
>>> objectSid: S-1-5-21-886655096-618523297-2770022155-502
>>> msDS-ResultantPSO: CN=dummy-PSO,CN=Password Settings 
>>> Container,CN=System,DC=WINDOWS2012R2,DC=WIN,DC=TIM,DC=WGTN,DC=CAT-IT,
>>> DC=
>>> CO,DC=NZ
>>>
>>> You can see the RID in the objectSid is 502, which is DOMAIN_USER_RID_KRBTGT. 
>>>
>>> Could you please clarify which is incorrect - the specification or the Windows behaviour? Or have I misunderstood something?
>>>
>>> Thanks,
>>> Tim
>>>
>>> [1]
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn
>>> .mi 
>>> crosoft.com%2Fen-us%2Flibrary%2Fcc223866.aspx&data=02%7C01%7Cdochelp%
>>> 40w
>>> indows.microsoft.com%7Ce172420a92714a01130f08d59b383228%7C72f988bf86f
>>> 141
>>> af91ab2d7cd011db47%7C1%7C0%7C636585588018722990&sdata=KdE0SNnF0Xy3GBj
>>> np8
>>> UKzXt4GB9xQ2j0fFKuUZaD9JI%3D&reserved=0
>>>
>>>