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

Thu Apr 26 19:28:03 UTC 2018

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
>>
>>