Arjun Singh wrote:
> I'm trying to set up an ldap server on FreeBSD 7.1-RELEASE.
> 
> I installed all of the latest versions of openldap24-server,
> openldap24-client, nss_ldap, and pam_ldap.
> 
> When I do any sort of ldapsearch or 'getent passwd' or anything, everything
> works perfectly. The only time I have trouble is when I'm logging in via
> SSH..then it gets really weird.
> 
> 1.) When I log in as a user in LDAP only and give the incorrect password
> first and then supply the correct password, everything works fine. If the
> user is in wheel, I can sudo.
> 2.) When I log in as the same user and give only the correct password the
> first time, it hangs for roughly 45 seconds and then lets me in. Even though
> this user is in wheel, it says that the user is not in the sudoers file.
> 
> Here are the log messages I get in auth.log that correspond to the events
> above:
> 
> sshd[54031]: pam_ldap: error trying to bind as user "uid=user..(cut)..."
> (Invalid credentials) # This is the incorrect pw
> sshd[54029]: error: PAM: authentication error for user from localhost
> #Incorrect pw
> sshd[54032]: nss_ldap: could not search LDAP server - Server is unavailable
> # correct pw
> sshd[54029]: Accepted keyboard-interactive/pam for user from localhost port
> 32935 ssh2 #correct pw
> 
> When I enter just the right password, the first time, I get this in the log:
> 
> sshd[54047]: Accepted keyboard-interactive/pam for user from localhost port
> 51972 ssh2
> sshd[54050]: nss_ldap: could not get LDAP result - Can't contact LDAP server
> 
> Again, when SSL/TLS are disabled, I get normal log output and none of the
> weird stuff above..
> 
> I turned on debugging in nss_ldap.conf and found that each time I gave only
> the correct password (corresponding with the 45 second hang) I found this in
> the debug output:
> 
> ...bunch of normal looking output...
> ldap_chkResponseList ld 0x801b31480 msgid 5 all 0
> ldap_chkResponseList returns ld 0x801b31480 NULL
> ldap_int_select
> read1msg: ld 0x801b31480 msgid 5 all 0
> ber_get_next
> TLS trace: SSL3 alert write:fatal:bad record mac <--- what is the cause of
> this?
> ldap_free_connection 1 0
> ldap_free_connection: actually freed
> ldap_err2string
> ldap_result ld 0x801b31480 msgid 5
> wait4msg ld 0x801b31480 msgid 5 (timeout 30000000 usec)
> wait4msg continue ld 0x801b31480 msgid 5 all 0
> ** ld 0x801b31480 Connections:
> ** ld 0x801b31480 Outstanding Requests:
>    Empty
>   ld 0x801b31480 request count 0 (abandoned 0)
> ** ld 0x801b31480 Response Queue:
>    Empty
> 
> I get the above regardless of whether I'm using start_tls or ssl.
> 
> If you have any insight, it'd be really useful. I've spent tons of time
> scouring lists for help and haven't found anything yet..

I don't have any more insight into the problem other than to say we've
had some similar issues in our environment. Initial password-based
logins do not have groups initialized, but SSH key logins and /bin/login
logins have groups initialized successfully.

We were piloting nscd on some of our 7.0 boxes. It turns out that
enabling nscd was a successful workaround. We have since enabled it on
the rest of our 7.0 installations.

Anyone out there have ideas?

-- 
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley

Attachment: pgp9oeSAgHp3M.pgp
Description: PGP signature

Reply via email to