[cifs-protocol] [EXTERNAL] [MS-SAMR] 3.1.1.7.1 General Password Policy -- interaction with LDAP_SERVER_POLICY_HINTS_OID - TrackingID#2509240040013358

Douglas Bagnall douglas.bagnall at catalyst.net.nz
Wed Oct 15 01:22:24 UTC 2025


hi Obaid,

That doesn't quite answer everything.

I understand that it isn't used for a password set for a new user, but I 
think it is used for a password *reset* for an existing user.

My understanding is a password reset doesn't require the existing 
password, and it ignores or wipes password history. A password change 
requires the user enter their old password and checks it against history.

A password change in Entra ID using the self-service password reset 
writeback system wants to enforce on-premises password policy, even 
though it is not providing the old password to the on-prem AD server:

https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-writeback

   Enforcement of on-premises Active Directory Domain Services (AD DS)
   password policies: When a user resets their password, it's checked to
   ensure it meets your on-premises AD DS policy before committing it to
   that directory. This review includes checking the history, complexity,
   age, password filters, and any other password restrictions that you
   define in AD DS.

I *think* it does this by sending a reset message with the OID, and the 
OID means "this reset should check policy as if it were a change". But 
MS-SAMR 3.1.1.7.1 doesn't mention it. Should it? that was my original 
question.

Now that I look at that passage again, it seems like the OID should also 
affect the minimum password length constraint in MS-SAMR 3.1.1.7.1, but 
MS-ADTS does not mention that (just the history). The complexity and 
"other password restrictions" looks to refer to MS-SAMR 3.1.1.7.2, which
doesn't use the language of "change" or "set", but says "this constraint 
is referenced when a cleartext password is updated". Should MS-ADTS also 
mention that? Or is the self-service password reset document wrong?

I am not able to get a trace of the this happening with Entra ID, but I 
have seen a pcap showing that the (deprecated) OID is set in this case. 
I am able to write a test case that mimics it.

cheers,
Douglas



On 15/10/25 12:31, Obaid Farooqi wrote:
> Hi Douglas:
> Based on my research LDAP_SERVER_POLICY_HINTS_OID is only used for change password. I did not see evidence for it to be used in the add scenario for a new user. This is based on code browsing.
> 
> I have filed a bug to fix MS-ADTS. If my above assumption is incorrect (highly unlikely) and the control is used for both set and change, I'll update you.
> 
> Please let me know if this does not answer your question.
> 
> Regards,
> Obaid Farooqi
> Sr. Escalation Engineer | Microsoft
> 
> -----Original Message-----
> From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
> Sent: Wednesday, October 8, 2025 6:38 PM
> To: Obaid Farooqi <obaidf at microsoft.com>
> Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
> Subject: Re: [cifs-protocol] [EXTERNAL] [MS-SAMR] 3.1.1.7.1 General Password Policy -- interaction with LDAP_SERVER_POLICY_HINTS_OID - TrackingID#2509240040013358
> 
> hi again.
> 
> I noticed from this message to the Samba users list
> 
> https://lists.samba.org/archive/samba/2024-August/249724.html
> 
> that Keycloak also uses the LDAP_SERVER_POLICY_HINTS_OID.
> 
> The way they document it is "if [some option is] on, then updating password of MSAD user will use LDAP_SERVER_POLICY_HINTS_OID extension, which means that advanced MSAD password policies like 'password history'
> or 'minimal password age' will be applied. This extension works just for MSAD 2008 R2 or newer."
> 
> (https://github.com/keycloak/keycloak/blob/main/js/apps/admin-ui/maven-resources/theme/keycloak.v2/admin/messages/messages_en.properties#L97).
> 
> I guess Keycloak is trying to do the same thing as Entra, enforcing password change semantics without giving AD the old password.
> 
> Douglas
> 
> 
> On 1/10/25 10:33, Douglas Bagnall via cifs-protocol wrote:
>> hi Obaid,
>>
>> Thanks for looking.
>>
>> If it helps, Azure Self-Service Password Reset does set the control
>> (actually LDAP_SERVER_POLICY_HINTS_DEPRECATED_OID which does the same
>> thing) when doing a password set.
>>
>> I think maybe it looks like a password change on the Entra side (that
>> is, the user needs their old password), but Entra wants to forward the
>> change as an unconditional set but maintain history.
>>
>> This page
>>
>> https://lear/
>> n.microsoft.com%2Fen-us%2Fentra%2Fidentity%2Fauthentication%2F&data=05
>> %7C02%7Cobaidf%40microsoft.com%7C37bbfc9a6456405eed3508de06c3c419%7C72
>> f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638955635072994735%7CUnknown%
>> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
>> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WyH8Xrqt8E9lJy
>> %2FS%2F5aPpuOXRis2oIV%2FeEDytOpGQEc%3D&reserved=0
>> troubleshoot-sspr-writeback#if-the-source-of-the-event-is-adsync
>>
>> talks a bit about it around "33008 ADPasswordPolicyError". Elsewhere
>> it mentions LDAP_SERVER_POLICY_HINTS_OID but gives it the value
>> 1.2.840.113556.1.4.2066 which is the one now called _DEPRECATED_,
>> presumably because the oid is also used for the ms-DS-Required-Domain-
>> Behavior-Version attribute.
>>
>> Douglas
>>
>>
>>
>> On 1/10/25 10:02, Obaid Farooqi wrote:
>>> Hi Douglas:
>>> To me, the quote from MS-ADTS looks more problematic than the MS-SMAR's.
>>> There will not be a password history if we are setting a password.
>>>
>>> I am looking into it and I think this is a bug in MS-ADTS.
>>>
>>> Regards,
>>> Obaid Farooqi
>>> Sr. Escalation Engineer | Microsoft
>>>
>>> -----Original Message-----
>>> From: Michael Bowen <Mike.Bowen at microsoft.com>
>>> Sent: Wednesday, September 24, 2025 6:17 PM
>>> To: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>; cifs-
>>> protocol at lists.samba.org
>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>> Subject: RE: [EXTERNAL] [MS-SAMR] 3.1.1.7.1 General Password Policy
>>> -- interaction with LDAP_SERVER_POLICY_HINTS_OID -
>>> TrackingID#2509240040013358
>>>
>>> [DocHelp to bcc]
>>>
>>> Hi Douglas,
>>>
>>> Thanks for your question. I've created case number 2509240040013358
>>> to track this issue. Please leave the number in the subject line and
>>> use reply all your correspondence. One of our engineers will contact
>>> you soon.
>>>
>>> Best regards,
>>> Michael Bowen
>>>
>>> Sr. Escalation Engineer - Microsoft(r) Corporation
>>>
>>>
>>> -----Original Message-----
>>> From: Douglas Bagnall <douglas.bagnall at catalyst.net.nz>
>>> Sent: Wednesday, September 24, 2025 3:39 PM
>>> To: Interoperability Documentation Help <dochelp at microsoft.com>;
>>> cifs- protocol at lists.samba.org
>>> Subject: [EXTERNAL] [MS-SAMR] 3.1.1.7.1 General Password Policy --
>>> interaction with LDAP_SERVER_POLICY_HINTS_OID
>>>
>>> hi Dochelp,
>>>
>>> MS-ADTS 3.1.1.3.4.1.27 says that when LDAP_SERVER_POLICY_HINTS_OID is
>>> used with a control value of 1, the password history length
>>> constraint is enforced on password-set operations.
>>>
>>> I think that means at the bottom of MS-SAMR 3.1.1.7.1 General
>>> Password Policy, where it says:
>>>
>>>> 5. The requesting protocol message is a password change (as compared
>>>> to a password set).
>>>
>>> it should say something like
>>>
>>> 5. The requesting protocol message is a password change (as compared
>>> to a password set), or the message is a password set with the
>>> LDAP_SERVER_POLICY_HINTS_OID control set with the value 0x1.
>>>
>>> Is that right?
>>>
>>> Douglas
>>>
>>
>>
>> _______________________________________________
>> cifs-protocol mailing list
>> cifs-protocol at lists.samba.org
>> https://list/
>> s.samba.org%2Fmailman%2Flistinfo%2Fcifs-protocol&data=05%7C02%7Cobaidf
>> %40microsoft.com%7C37bbfc9a6456405eed3508de06c3c419%7C72f988bf86f141af
>> 91ab2d7cd011db47%7C1%7C0%7C638955635073003873%7CUnknown%7CTWFpbGZsb3d8
>> eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Y2rxWtoBTT%2FLV%2Fjs8SkToXsY
>> snQe%2FbZ5C6q0jIj3QAc%3D&reserved=0
> 




More information about the cifs-protocol mailing list