Re: It does not change password in LDAP Windows 2012 R2

Hi francism8!

I do not claim any significant knowledge of Windows 2012 R2 AD (Active Directory). However, I hope by asking a few (perhaps "dumb") questions, that you may be able to see something that I do not? Your code looks fundamentally sound to me (the flow and error checking appear to be ok). The main difference appears to be in how the 2 servers are configured.

First, a lot changes happen by moving from LDAPS (Secure LDAP), port 636 in Win 2008 R2 to plain LDAP, port 389 in Win 2012. That direction is usually much easier than moving from a plain connection to an encrypted connection. I don't know why that change in connection protocol was done, but it appears to work.

As a rather bizarre idea, I considered the idea that your code is actually "working" as written, although it is not achieving the desired result (actual password change).

I do not know why you changed from setting "unicodePwd" to setting the "userPassword"? So I investigated that.

I found this on a site that I do not want to advertise here, but:

unicodePwd is the "real password attribute", That's what is used for user binds. It has a very specific formatting requirements. Whenever you set a value, it must be a unicode string enclosed in double quotes.
userPassword is "switchable". It can be turned into a regular attribute, or it can be turned into a write-alias for unicodePwd. AD by default has it as a regular attribute. When userPassword is a write-alias for unicodePwd, it is written as a regular value, no unicode, no double-quotes. However, passwords can never be read.

So one theory could be that you are successfully setting "userPassword" as a regular attribute. But that doesn't actually change the "unicodePwd" because AD (Active Directory) default for this field has not been configured as a write only alias for "unicodePwd". Essentially you change "userPassword", but it doesn't matter? There appear to be some formatting details when using the "unicodePwd" alias.

If you are able to read "userPassword", that would indicate that it is not an alias for "unicodePwd" because "real passwords" cannot be read. Try it and see what happens.

I looked at Microsoft site: unicodePwd attribute and this attribute appears to be the same between Win 2008 R2 and 2012 R2.

Hope these questions help you.

Comment on Re: It does not change password in LDAP Windows 2012 R2

Replies are listed 'Best First'.
Re^2: It does not change password in LDAP Windows 2012 R2 by francism8 (Novice) on Feb 23, 2017 at 06:03 UTC
Dear Marshall, Thanks for bringing this to my attention and after scratching my head on what was the issue I read some forum in the PHP community that uses LDAP also for their code and they mentioned that it should be in secure connection in order to change the attributes in Ldap. This attribute is written by an LDAP Modify under the following restricted conditions. Windows 2000 operating system servers require that the client have a 128-bit (or better) SSL/TLS-encrypted connection to the DC in order to modify this attribute. On Windows Server 2003 operating system, Windows Server 2008 operating system, Windows Server 2008 R2 operating system, Windows Server 2012 operating system, Windows Server 2012 R2 operating system, and Windows Server 2016 Technical Preview operating system, the DC also permits modification of the unicodePwd attribute on a connection protected by 128-bit (or better) Simple Authentication and Security Layer (SASL)-layer encryption instead of SSL/TLS. In Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016 Technical Preview, if the fAllowPasswordOperationsOverNonSecureConnection heuristic of the dSHeuristics attribute (section 6.1.1.2.4.1.2) is true and Active Directory is operating as AD LDS, then the DC permits modification of the unicodePwd attribute over a connection that is neither SSL/TLS-encrypted nor SASL-encrypted. The unicodePwd attribute is never returned by an LDAP search. and so after reconfiguring the Windows 2012 to enable the "Active Directory Certificate Services feature" and TADA.. it works... and so I use this code `$result = $ad->modify($dn, replace => {"unicodePwd" => $unicodePwd}); my $ad=Net::LDAP->new($adsvr, version => 3, scheme => 'ldaps', port=> +636,) or die "can't connect to $adsvr: $@";` [download] Hope someone can help this in future. We can mark this as resolve and can be close :D.	[reply] [d/l]
Re^3: It does not change password in LDAP Windows 2012 R2 by fsmendoza (Novice) on Feb 24, 2017 at 08:36 UTC
Dear Francism08, There's another way to this instead of installing the "Active Directory Certificate Services Feature" you can just import SSL certificate in the "Trusted Root Certification Authorityies" below is the step to create self signed certificate in your Windows 2012 R2 AD Server powershell running as Administrator without the need of enabling the AD CS feature. Step1: New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname win2012r2t3.dev.fsmendoza.com Step2: $pwd = ConvertTo-SecureString -String 'P@ssw0rd' -Force -AsPlainText Step3: Export-PfxCertificate -cert cert:\localMachine\my\E72FD6F54234EDC717420F4C9FF8DBD68093D85F -FilePath c:\tmp\cert.pfx -Password $pwd Note:The E72FD6F54234EDC717420F4C9FF8DBD68093D85F - is the number that will show in Step 1: Step4: double click teh cert.pfx that was created in c:\tmp and install in "Trusted Root Certification Authorityies" and done. This one required reboot of the server to apply.	[reply]
Re^3: It does not change password in LDAP Windows 2012 R2 by fsmendoza (Novice) on Feb 23, 2017 at 08:35 UTC
Thanks	[reply]


more useful options
	PerlMonks