On Thu, 2005-12-22 at 08:07 -0600, Jim Summers wrote: > Jim Summers wrote: > >> Where -D is the id listed as proxyagent in ldap.conf, and the password > >> supplied is for that id. If userPassword is returned then you know what > >> is going on. > >> > >> If this is not what is happening, check and make sure you don't have > >> rootbinddn and /etc/ldap.secret set up. If it is actually binding as > >> your rootdn then that is what it could be as well. > > > > > > Welp, I am stumped. Running various ldapsearchs I got the results as > > they should be. Binding as the proxy, no userPassword, binding as an > > admin then I get the userPassword. > > > > I looked in /etc/ and there is not an ldap.secret file, so I guess I do > > not have the rootbinddn setup. > > > > I was thinking of removing the shadowExpire attributes but I am afraid > > if I do that then cron may stop working. > > > > Not sure at this point. > > Was doing some more testing this morning. Following along in my > messages file, I noticed that when the testuser logs in, messages are > being logged with pam_unix as the service, for example: > > Dec 22 07:56:03 xxxxxxx sshd(pam_unix)[18339]: check pass; user unknown > Dec 22 07:56:03 xxxxxxx sshd(pam_unix)[18339]: authentication failure; > logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=karp.cs.ou.edu > Dec 22 07:56:03 xxxxxxx sshd(pam_unix)[18342]: session opened for user > tulsa by (uid=9018) > That means it has to be getting the user's encrypted password string some how. This is what I would do: 1. Check the access log and see who the binddn of the connection that looks up the user is (find the SRCH filter that is looking up the user id, then grep conn=<that connection number> to see the full connection. Find the bind associated). This will verify the proxy account, even though we have verified that already. 2. Get a tcpdump of the traffic (tcpdump -i eth0 -s 1500 host ldapsrv and port ldap ) while you are logging in. The 'port ldap' assumes this is going over 389 unencrypted. If you are using TLS, you will need to disable it so you can get a good tcpdump of the LDAP session. Once you have this, load it up in ethereal, and start looking at the LDAP packets. You will be able to expand out the searches, and results. The important thing here is to make sure that when userPassword is requested (will be several times) that a response is never given in the search result. 3. In the console, right-click on the tulsa user, and select "Set Access Permissions". When that box comes up, select the "Show Inherited ACIs" Review all those to make sure that some place along the way read access was not granted to the userPassword attribute. If we get this far without figuring it out I will be at a loss.... I am running out of ideas 8-) Jamie
