I have some scripts in Active Directory environments that use [ADSI] or [ADSISearcher], and for some I can't use the *et-AD* commandlets in PowerShell. PowerShell 5 is a requirement.
A few of them are affected by "new requirements for using LDAP clients to access confidential attributes" for Server 2025
https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/confidential-attributes-unexpected-behavior-using-windows-server-2025-dc
It is mentioned that it should work from a Server 2025 to a Server 2025 system but it doesn't - even when trying it locally. So the following is not true for ADSI LDAP in PowerShell?!
This behavior doesn't affect LDAP clients that run on Windows Server 2025-based member servers or Windows 11, version 24H2-based computers. On these operating system versions, LDAP clients use encrypted sessions by default.
I thought that it would be easy to fix, but I might not correctly use the required options "ADS_SECURE_AUTHENTICATION", "ADS_USE_SIGNING" and "ADS_USE_SEALING". Read about them there:
https://learn.microsoft.com/en-us/windows/win32/api/iads/ne-iads-ads_authentication_enum
My examples for your tests:
# Working:
$Path = "LDAP://CN=mytestobject,CN=Users,DC=example,DC=com"
$ADObject = [ADSI]$Path
$displayname = $ADObject.Get("displayName")
"Read old displayName as `"$displayname`""
$ADObject.Put("displayName","EXAMPLESuccess")
$ADObject.SetInfo()
# Not working
$Path = "LDAP://CN=mytestobject,CN=Users,DC=example,DC=com"
$ADObject = [ADSI]$Path
$acl = $ADObject.psbase.ObjectSecurity
try {
$ADObject.psbase.CommitChanges()
}
catch {
$_.Exception | fl * -force
$_.Exception.InnerException | fl * -force
}
Regarding the path ... I also tried with Servername (short or fqdn) and domain name as well:
$Path = "LDAP://CN=mytestobject,CN=Users,DC=example,DC=com"
$Path = "LDAP://server/CN=mytestobject,CN=Users,DC=example,DC=com"
$Path = "LDAP://server.example.com/CN=mytestobject,CN=Users,DC=example,DC=com"
The options were tried to be enabled like that or in different HEX or .net notations: $ADObject.Options = 193
The error is:
Exception calling "CommitChanges" with "0" argument(s):
"A constraint violation occurred."
The connection should stay on port 389, so only message level encryption not transport level encryption, as in some situations I use scripts when LDAPS is not ready yet, but Kerberos is.