Identical LDAP configuration on Backupserver and VE - different results

T

tglemser

New Member
Proxmox Subscriber
Dec 19, 2023
10
2
3
Hi,

we're running Proxmox VE and Backupserver. I configured our AD as LDAP-Server successfully on the Backupserver. With an identical configuration on both VE 8.1.3 and VE 7.4-15 the inital connection check works successfully. All syncs after that fail with an authentication error. Same applies for configuring it as "AD".

We double cross checked everything many times.

It seems to us, the password is used in the initial connection check, but not for the syncs afterwards. The password is stored correctly in /etc/pve/priv/realm/$realmname.pw

Any help is highly appreciated. Thanks in advance.
 
Hi,

tglemser said:
All syncs after that fail with an authentication error. Same applies for configuring it as "AD".
Click to expand...
what is the exact error message when the sync fails?
E.g. when you start a realm sync, what is the task output?

You can either do this via the web UI, or using pveum realm sync <realmname> on the shell.

Also, what implementation/version of AD do you use exactly?
Does the AD server log any errors during the failed authentication?
 
Thanks for your reply @cheiss
cheiss said:
E.g. when you start a realm sync, what is the task output?
Click to expand...
starting sync for realm $realm ldap bind failed: 80090308: LdapErr: DSID-0C09056B, comment: AcceptSecurityContext error, data 52e, v4f7c
I know it seems the credentials are wrong. They are not ☺️ The initial connection check when adding/editing the connection works. If I enter a wrong password, the connection check fails.
cheiss said:
Also, what implementation/version of AD do you use exactly?
Click to expand...
Windows Server 2022 Standard
cheiss said:
Does the AD server log any errors during the failed authentication?
Click to expand...
Yes. The inital connection when adding/editing the realm results in Event-ID 4624 (https://learn.microsoft.com/de-de/windows/security/threat-protection/auditing/event-4624)

Strange, but true: I see the same Event-ID when triggering the failing sync.
 
Last edited:
Interesting.
Could you please post the output of cat /etc/pve/domains.cfg, or at least the relevant section of the failing LDAP/AD realm? (Sensibly censoring base_dn and server1 as needed, of course).

Did you configure any special settings on Windows Server? Or is it pretty much the out-of-the-box configuration?

I will try to reproduce it and report back, fortunately I've got a similar test setup for that.
 
Thanks for getting back to me @cheiss
cheiss said:
Could you please post the output of cat /etc/pve/domains.cfg, or at least the relevant section of the failing LDAP/AD realm?
Click to expand...

ldap: domain.de
base_dn CN=Users,DC=domain,DC=de
server1 dc01.domain.de
user_attr sAMAccountName
bind_dn CN=UserForBind,CN=Users,DC=domain,DC=de
default 0
filter (&(memberOf=CN=GroupToUse,CN=Users,DC=domain,DC=de))
server2 dc02.domain.de
sync-defaults-options remove-vanished=acl;entry;properties,scope=both
cheiss said:
Did you configure any special settings on Windows Server? Or is it pretty much the out-of-the-box configuration?
Click to expand...
Pretty much out-of-the-box
cheiss said:
I will try to reproduce it and report back, fortunately I've got a similar test setup for that.
Click to expand...
Perfect. Thanks! If there is a way to force PVE to debug ldap, just let me know.
 
tglemser said:
bind_dn CN=UserForBind,CN=Users,DC=domain,DC=de
Click to expand...
What you can try is using instead the userPrincipalName of the bind user (using Get-ADUser in Powershell), or User logon name in the GUI of AD), to see if that changes anything. It's a weird thing that works with AD servers, even though LDAP is used as protocol.
It should be in the form of <username>@<domain.tld>.

I now have tried some combinations, even using the exact same domain configuration as you, but could not (yet) reproduce it. (Also WS2022 Standard)

One last thing that might be useful is a complete properties dump of the bind user, using Get-ADUser -Identity <binduser> -Properties * in Powershell. That way I could diff and see if any properties related to authentication etc. are set differently.

tglemser said:
Perfect. Thanks! If there is a way to force PVE to debug ldap, just let me know.
Click to expand...
Unfortunately, not really. You can look if the syslog (journalctl -b) contains any additional error information pertaining to that, but everything you see in the task log is basically the whole log.
 
cheiss said:
What you can try is using instead the userPrincipalName of the bind user (using Get-ADUser in Powershell), or User logon name in the GUI of AD), to see if that changes anything. It's a weird thing that works with AD servers, even though LDAP is used as protocol.
It should be in the form of <username>@<domain.tld>.
Click to expand...
I tried almost everything, and yes: username@domain.de works as well for the initial connection check, but not for everything else
cheiss said:
One last thing that might be useful is a complete properties dump of the bind user, using Get-ADUser -Identity <binduser> -Properties * in Powershell. That way I could diff and see if any properties related to authentication etc. are set differently.
Click to expand...
AccountExpirationDate :
accountExpires : 9223372036854775807
AccountLockoutTime :
AccountNotDelegated : False
AllowReversiblePasswordEncryption : False
AuthenticationPolicy : {}
AuthenticationPolicySilo : {}
BadLogonCount : 0
badPasswordTime : 133494498226291701
badPwdCount : 0
CannotChangePassword : True
CanonicalName : domain.de/Users/Username
Certificates : {}
City :
CN : Username
codePage : 0
Company :
CompoundIdentitySupported : {}
Country :
countryCode : 0
Created : 10.01.2019 12:00:13
createTimeStamp : 10.01.2019 12:00:13
Deleted :
Department :
Description :
DisplayName : Username
DistinguishedName : CN=Username,CN=Users,DC=domain,DC=de
Division :
DoesNotRequirePreAuth : False
dSCorePropagationData : {27.03.2023 10:07:05, 25.03.2023 10:46:15, 12.05.2022
21:11:47, 03.03.2021 22:10:01...}
EmailAddress :
EmployeeID :
EmployeeNumber :
Enabled : True
Fax :
GivenName : Username
HomeDirectory :
HomedirRequired : False
HomeDrive :
HomePage :
HomePhone :
Initials :
instanceType : 4
isDeleted :
KerberosEncryptionType : {}
LastBadPasswordAttempt : 11.01.2024 13:30:22
LastKnownParent :
lastLogoff : 0
lastLogon : 133494499302943860
LastLogonDate : 08.01.2024 13:19:37
lastLogonTimestamp : 133491899773255442
LockedOut : False
lockoutTime : 0
logonCount : 65535
LogonWorkstations :
Manager :
MemberOf : {}
MNSLogonAccount : False
MobilePhone :
Modified : 11.01.2024 13:32:10
modifyTimeStamp : 11.01.2024 13:32:10
msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon : 0
msDS-LastSuccessfulInteractiveLogonTime : 133494499302943860
msDS-User-Account-Control-Computed : 0
Name : Username
nTSecurityDescriptor : System.DirectoryServices.ActiveDirectorySecurity
ObjectCategory : CN=Person,CN=Schema,CN=Configuration,DC=domain,DC=de
ObjectClass : user
ObjectGUID : xxxx-xxxx-xxx-xxx-xxxxxx
objectSid : S-xxxx-xxxx-xxxx-xxxx
Office :
OfficePhone :
Organization :
OtherName :
PasswordExpired : False
PasswordLastSet : xx.xx.20xx 18:24:11
PasswordNeverExpires : True
PasswordNotRequired : False
POBox :
PostalCode :
PrimaryGroup : CN=Domänen-Benutzer,CN=Users,DC=domain,DC=de
primaryGroupID : 513
PrincipalsAllowedToDelegateToAccount : {}
ProfilePath :
ProtectedFromAccidentalDeletion : False
pwdLastSet : xxxxxxxxxxxx
SamAccountName : Username
sAMAccountType : 805306368
ScriptPath :
sDRightsEffective : 15
ServicePrincipalNames : {}
SID : S-1-5-21-2501045716-178712919-340273635-3173
SIDHistory : {}
SmartcardLogonRequired : False
State :
StreetAddress :
Surname :
Title :
TrustedForDelegation : False
TrustedToAuthForDelegation : False
UseDESKeyOnly : False
userAccountControl : 66048
userCertificate : {}
UserPrincipalName : Username@domain.de
uSNChanged : 24627482
uSNCreated : 5478890
whenChanged : 11.01.2024 13:32:10
whenCreated : 10.01.2019 12:00:13
cheiss said:
Unfortunately, not really. You can look if the syslog (journalctl -b) contains any additional error information pertaining to that, but everything you see in the task log is basically the whole log.
Click to expand...
Nothing.

What I noticed by reviewing the "Get-ADUser": The sync IS a bad password login attempt.

Connection check when editing the connection with a wrong password: Bad password attempt gets a new timestamp.
Connection check when editing the connection with the correct password: Bad password attempt gets no new timestamp.
Sync: Bad password attempt gets a new timestamp.
 
Got it. I played around with the password and found the bug (dump testing procedure btw and a waste of time).

@cheiss Could you please add a "§" (section sign) to your password? I would expect the initial connection check to work and the sync to fail.

Can you reproduce this?
 
tglemser said:
@cheiss Could you please add a "§" (section sign) to your password? I would expect the initial connection check to work and the sync to fail.
Click to expand...
Yes, I can reproduce that.

This is connected to bug #1909, from the looks of it.
Inspecting the raw password in /etc/pve/priv/realm/name.pw reveals that the section sign (or for that matter, any non-ASCII-character) gets incorrectly encoded.

Can you try setting the password manually using nano -L /etc/pve/priv/realm/name.pw? This will save the password correctly.
Notice the -L flag to nano, this is needed as it prevents it from adding a newline at the end.
 
You must log in or register to reply here.
Top Bottom