hi Obaid,
I have tested against Windows 2022.
If I do this as Administrator:
dn: cn=testuser,cn=users,DC=samba,DC=example,DC=com
changetype: modify
replace: unicodePwd
unicodePwd:: <base64 encoded recent password>
it fails (unwillingToPerform) if the LDAP_SERVER_POLICY_HINTS_OID
control is set with a value of 1.
If I have control unset, or the value set to a different number, the
reset succeeds.
It also succeeds with the control set to 1 if the password is not a
recent password.
I am struggling to install TTD, but I will keep trying!
Douglas
On 16/10/2025 12:24, Obaid Farooqi wrote:
Hi Douglas:
This is what I did:
1. logged in on a workstation as admin
2. Open ADSI edit
3. Modified the unicodePwd attribute of a user (just an ordinary user testuser)
4. Logged in as testuser using new password and it worked.
5. this IMO is a password reset scenario since I am not the user whose password
is being changed.
5. debugged the scenario and here is what I found
LDAP operation is modify
ADSI editor does not send the control LDAP_SERVER_POLICY_HINTS_OID
Since after debugging I know where to look, I browse the code to where else
this control is meaningful. It is only meaningful in modify operation and here
what happens:
If (the attribute being modified is password or Unicode password)
{
If (LDAP_SERVER_POLICY_HINTS_OID is 1)
{
Calculate the time when user is allowed to change the password
by using when the password last change and what is minimum time after which the
password can be changed
If (calculated time > current time)
{
Return error STATUS_PASSWORD_RESTRICTION
}
}
}
This is all this control do.
If you can send the exact LDAP message in a test environment that entra ID
sends to Windows DC and collect TTD traces for that, I'll look at it.
Regards,
Obaid Farooqi
Sr. Escalation Engineer | Microsoft
-----Original Message-----
From: Douglas Bagnall <[email protected]>
Sent: Tuesday, October 14, 2025 8:22 PM
To: Obaid Farooqi <[email protected]>
Cc: [email protected]; Microsoft Support <[email protected]>
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 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 <[email protected]>
Sent: Wednesday, October 8, 2025 6:38 PM
To: Obaid Farooqi <[email protected]>
Cc: [email protected]; Microsoft Support
<[email protected]>
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://list/
s.samba.org%2Farchive%2Fsamba%2F2024-August%2F249724.html&data=05%7C02
%7Cobaidf%40microsoft.com%7C404c0c2b3f264975954008de0b894dd3%7C72f988b
f86f141af91ab2d7cd011db47%7C1%7C0%7C638960881535058119%7CUnknown%7CTWF
pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MhyxSJvWbPxWBF9y2qJ
Tu%2BaKyoApimkXl2JqFiQDv7s%3D&reserved=0
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=0
5
%7C02%7Cobaidf%40microsoft.com%7C37bbfc9a6456405eed3508de06c3c419%7C7
2
f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638955635072994735%7CUnknown
%
7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4
z
MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WyH8Xrqt8E9lJ
y
%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 <[email protected]>
Sent: Wednesday, September 24, 2025 6:17 PM
To: Douglas Bagnall <[email protected]>; cifs-
[email protected]
Cc: Microsoft Support <[email protected]>
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 <[email protected]>
Sent: Wednesday, September 24, 2025 3:39 PM
To: Interoperability Documentation Help <[email protected]>;
cifs- [email protected]
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
[email protected]
https://list/
s.samba.org%2Fmailman%2Flistinfo%2Fcifs-protocol&data=05%7C02%7Cobaid
f
%40microsoft.com%7C37bbfc9a6456405eed3508de06c3c419%7C72f988bf86f141a
f
91ab2d7cd011db47%7C1%7C0%7C638955635073003873%7CUnknown%7CTWFpbGZsb3d
8
eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT
W
FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Y2rxWtoBTT%2FLV%2Fjs8SkToXs
Y
snQe%2FbZ5C6q0jIj3QAc%3D&reserved=0
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
