LDAP Authentication

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?

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.

[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.

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

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

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.

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.