# LDAP Authentication **URL:** \ **Category:** SLES Configure-Administer\ **Created:** [April 2, 2019, 3:42pm UTC](https://forums.suse.com/t/ldap-authentication/33751 "2019-04-02T15:42:38Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![grahamch](https://avatars.discourse-cdn.com/v4/letter/g/5f8ce5/32.png) [@grahamch](https://forums.suse.com/u/grahamch)\ **Post date:** [April 2, 2019, 3:42pm UTC](https://forums.suse.com/t/ldap-authentication/33751/1 "2019-04-02T15:42:38Z")
Hello, We have a rather peculiar issue. We have our SLES (non OES) servers setup to use LDAP authentication against our eDirectory tree, for SSH. We have configured the systems so that only the IT OU is allowed to authenticate via LDAP on these servers. The issue is that if the username starts with an S, the person is not able to authenticate. Accounts that begin with any other letter have no issue authenticating. I’ve been able to recreate this with three different accounts and even found the same issue on an old SLES 11.3. Something I have noticed in the messages log is that when an account is successful, the log entries start as follows: pam\_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx user=boba When the account starts with an S, the log entry starting line does not include the user=…: pam\_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx Has anybody run into anything like this? ---
**Author:** ![system](https://us1.discourse-cdn.com/flex022/uploads/suse/original/2X/5/5012ba89e3ffb5220dac47d5ea0ba032e2fe1cb6.png) [@system](https://forums.suse.com/u/system)\ **Post date:** [April 3, 2019, 5:08pm UTC](https://forums.suse.com/t/ldap-authentication/33751/2 "2019-04-03T17:08:05Z")
On 04/02/2019 06:44 AM, grahamch wrote:[color=blue] > We have a rather peculiar issue. We have our SLES (non OES) servers > setup to use LDAP authentication against our eDirectory tree, for SSH. > We have configured the systems so that only the IT OU is allowed to > authenticate via LDAP on these servers.[/color] Sounds great so far. [color=blue] > The issue is that if the username starts with an S, the person is not > able to authenticate. Accounts that begin with any other letter have no > issue authenticating. I’ve been able to recreate this with three > different accounts and even found the same issue on an old SLES 11.3.[/color] Out of curiosity, were any of these accounts you created recently specifically for testing this issue, or were the all previously existing? I’m just curious about eDirectory rights, and that may help learn more about the situation. [color=blue] > Something I have noticed in the messages log is that when an account is > successful, the log entries start as follows: > pam\_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 > tty=ssh ruser= rhost=xxx.xxx.xxx.xxx user=boba[/color] Just to be clear, you wrote that “when an account is successful” but this message has “authentication failure” in its text. Is that all correct? [color=blue] > When the account starts with an S, the log entry starting line does not > include the user=…: > pam\_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 > tty=ssh ruser= rhost=xxx.xxx.xxx.xxx > > Has anybody run into anything like this?[/color] Since you have eDirectory you may be able to get some good information from ndstrace with +TIME +TAGS +LDAP assuming you have the trace/log-level settings turned up on the LDAP Server object. It would be interesting to see a successful user vs. an unsuccessful user on that side just to rule in/out the LDAP server side. – Good luck. If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below. If you want to send me a private message, please let me know in the forum as I do not use the web interface often. ---
**Author:** ![grahamch](https://avatars.discourse-cdn.com/v4/letter/g/5f8ce5/32.png) [@grahamch](https://forums.suse.com/u/grahamch)\ **Post date:** [April 3, 2019, 6:40pm UTC](https://forums.suse.com/t/ldap-authentication/33751/3 "2019-04-03T18:40:48Z")
[COLOR=“#0000FF”]\>Out of curiosity, were any of these accounts you created recently > specifically for testing this issue, or were the all previously existing? > I’m just curious about eDirectory rights, and that may help learn more > about the situation.[/COLOR] No, they’ve all been around for at least a few years. One better than 20. This is probably the first time that any these people have attempted to log in this way. [COLOR=“#0000FF”]\>Just to be clear, you wrote that “when an account is successful” but this > message has “authentication failure” in its text. Is that all correct?[/COLOR] Yes. This was the first entry in the log when a successful connection is established. The rest of the entries are: pam\_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx user=boba sshd[17981]: Accepted keyboard-interactive/pam for boba from xxx.xxx.xxx.xxx port 58817 ssh2 sshd[17981]: pam\_unix(sshd:session): session opened for user boba by (uid=0) systemd[1]: Created slice User Slice of boba. systemd[1]: Starting User Manager for UID 617… systemd[1]: Started Session 3736 of user boba. Whereas the unsuccessful entries are: pam\_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx sshd[15607]: pam\_ldap: error trying to bind as user “cn=stiensf,ou=IT,ou=Branch,o=Org” (Invalid credentials) sshd[15605]: error: PAM: Authentication failure for illegal user searchn from xxx.xxx.xxx.xxx sshd[15605]: Failed keyboard-interactive/pam for invalid user searchn from xxx.xxx.xxx.xxx port 53543 ssh2 sshd[15609]: gkr-pam: error looking up user information sshd[15605]: Postponed keyboard-interactive for invalid user searchn from xxx.xxx.xxx.xxx port 53543 ssh2 [preauth] [COLOR=“#0000FF”]\>Since you have eDirectory you may be able to get some good information > from ndstrace with +TIME +TAGS +LDAP assuming you have the trace/log-level > settings turned up on the LDAP Server object. It would be interesting to > see a successful user vs. an unsuccessful user on that side just to rule > in/out the LDAP server side.[/COLOR] Thanks, I’ll give that a try. ---
**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\ **Post date:** [April 3, 2019, 7:05pm UTC](https://forums.suse.com/t/ldap-authentication/33751/4 "2019-04-03T19:05:06Z")
Hi grahamch, [QUOTE=grahamch;57356][…] The rest of the entries are: pam\_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx user=boba sshd[17981]: Accepted keyboard-interactive/pam for boba from xxx.xxx.xxx.xxx port 58817 ssh2 sshd[17981]: pam\_unix(sshd:session): session opened for user boba by (uid=0) systemd[1]: Created slice User Slice of boba. systemd[1]: Starting User Manager for UID 617… systemd[1]: Started Session 3736 of user boba. Whereas the unsuccessful entries are: pam\_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx sshd[15607]: pam\_ldap: error trying to bind as user “cn=stiensf,ou=IT,ou=Branch,o=Org” (Invalid credentials) sshd[15605]: error: PAM: Authentication failure for illegal user searchn from xxx.xxx.xxx.xxx sshd[15605]: Failed keyboard-interactive/pam for invalid user searchn from xxx.xxx.xxx.xxx port 53543 ssh2 sshd[15609]: gkr-pam: error looking up user information sshd[15605]: Postponed keyboard-interactive for invalid user searchn from xxx.xxx.xxx.xxx port 53543 ssh2 [preauth] [/QUOTE] are you willing to share the configuration for pam\_ldap? Both from the pam config file for ssh (or where-ever pam\_ldad is included from, when going through /etc/pam.d/ssh) and the statements in /etc/ldap.conf, where I’m mostly interested in any DN mapping options (i. e. pam\_login\_attribute, pam\_filter). Something you could check is whether you have pam\_group\_dn defined and for some reason the affected users aren’t member of that group (i. e. because some deployment process has problems with the initial “s” when adding users to that group, maybe years ago). I’d also be interested in the results from tracing the LDAP queries, to see if the root cause is on PAM’s side or i. e. with the LDAP directory content. Regards, J ---
**Author:** ![grahamch](https://avatars.discourse-cdn.com/v4/letter/g/5f8ce5/32.png) [@grahamch](https://forums.suse.com/u/grahamch)\ **Post date:** [April 3, 2019, 9:21pm UTC](https://forums.suse.com/t/ldap-authentication/33751/5 "2019-04-03T21:21:32Z")
The ndstrace says a failed authentication. To verify that the person was entering the correct password, I had him type his password into a notepad session and then copy and paste it for the login process. 987760384 LDAP: [2019/04/03 14:01:50.229] Failed to authenticate local on connection 0x12b23180, err = failed authentication (-669) [QUOTE=jmozdzen;57357]Hi grahamch, are you willing to share the configuration for pam\_ldap? Both from the pam config file for ssh (or where-ever pam\_ldad is included from, when going through /etc/pam.d/ssh) and the statements in /etc/ldap.conf, where I’m mostly interested in any DN mapping options (i. e. pam\_login\_attribute, pam\_filter). Something you could check is whether you have pam\_group\_dn defined and for some reason the affected users aren’t member of that group (i. e. because some deployment process has problems with the initial “s” when adding users to that group, maybe years ago). I’d also be interested in the results from tracing the LDAP queries, to see if the root cause is on PAM’s side or i. e. with the LDAP directory content. Regards, J[/QUOTE] The only pam\_ldap file I can find on the system is in /usr/share/doc/packages/pam\_ldap/ and there is nothing set in that file for those options and the host is set to local host. /etc/pam.d/sshd `#%PAM-1.0 auth requisite pam_nologin.so auth include common-auth account requisite pam_nologin.so account include common-account password include common-password session required pam_loginuid.so session include common-session session optional pam_lastlog.so silent noupdate showfailed` /etc/ldap.conf `uri ldaps://ldap2.Domain.local ldaps://ldap1.Domain.local base ou=IT,ou=Branch,o=Org nss_connect_policy persist ssl yes` /etc/openldap/ldap.conf [CODE]# LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS\_REQCERT allow[/CODE] The instructions we used for setting up the ldap connection is as follows: [LIST=1] [_]Download Self-Signed Certificate from eDirectory CA (Export format should default to DER) [_]Copy the certificate to the SLES box [_]Connect to the SLES box (on console or via putty) [_]Copy the certificate to /usr/share/ssl [_]Execute openssl x509 -in /usr/share/ssl/.der -inform DER -out /usr/share/ssl/RootCert.pem -outform PEM [_] [_]edit /etc/openldap/ldap.conf [_]Add TLS\_REQCERT allow and save the file [_]Run YaST on the SLES box [_]Navigate to Network Services | LDAP and Kerberos Client [_]Click Change Settings [_]Check Allow LDAP Users To Authenticate and Automatically Create Home Directory [_]Check Users [_]In Enter LDAP server locations, enter ldaps://ldap2.Domain.local ldaps://ldap1.Domain.local [_]In DN of Search Base enter ou=IT,ou=Branch,o=Org [_]Select Secure Communication via TLS [_]Click the Authentication via Kerberos tab [_]Click Add Realm [_]In the Realm name, enter Tree [_]Click OK [_]Click the Use a Directory as Identity Provider (LDAP) tab [_]Click Test Connection to ensure it is working [_]Click OK [_]Click OK [/LIST] thanks Chris ---
**Author:** ![grahamch](https://avatars.discourse-cdn.com/v4/letter/g/5f8ce5/32.png) [@grahamch](https://forums.suse.com/u/grahamch)\ **Post date:** [April 4, 2019, 4:41pm UTC](https://forums.suse.com/t/ldap-authentication/33751/6 "2019-04-04T16:41:43Z")
I temporarily changed the authentication to use ldap (instead of ldaps) so that I could capture the traffic with Wireshark and see what password is being sent as part of the connection string. When an account successfully authenticates, I see the password as expected. When an account does not successfully authenticates the password that is being sent is \b \r\1771INCORREC I am seeing it where the account name starts with other characters now too. ---
**Author:** ![grahamch](https://avatars.discourse-cdn.com/v4/letter/g/5f8ce5/32.png) [@grahamch](https://forums.suse.com/u/grahamch)\ **Post date:** [April 4, 2019, 8:22pm UTC](https://forums.suse.com/t/ldap-authentication/33751/7 "2019-04-04T20:22:39Z")
Did some digging into the attributes of the accounts that were having problems. It turns out that even though the servers being logged into were not OES, the accounts still need to be set up as LUM accounts in iManager.