This content has been marked as final. Show 9 replies
I suspect the password of proxyAgent had expired.
Did you play with the Global Password Policy? If you did, some operational attributes will be there in cn=proxyAgent.
Take a look at cn=proxyAgent, using "Edit with Generic Editor", if there is one such attribute called passwordexpirationtime, set its value to many years later, eg: 20381231000000Z
I suspect the password of proxyAgent had expired.I don't think so:
That's 8/29 of this year. Not expired, yet (that's definitely something I gotta deal with now, but it's not the cause of the problem at hand)
Did you play with the Global Password Policy? If youI did update the password policy using the console, but didn't do anything that explicitly affected the proxyagent user. I set up account lockouts, password attempts, etc.
did, some operational attributes will be there in
Also, note that I did find out that a password failure when attempting to log in via ssh will yield the error message that I mentioned. I'm just trying to figure out where the actual login failure message is logged. I looked through my access logs on the DS server and found the bind and such, but I never found any errors to indicate that anything was wrong (!) .
Someone had posted some hints to troubleshoot BIND and SRCH issues in access log, not sure if it would help you.
Troubleshooting LDAP Search issue in access log
(From Fedora Directory Server mail list archive)
Look in the access log on the FDS server for connections from that workstation (grep on the IP of that workstations, or one of the user id's that are trying to auth, etc). When you find it, grep out conn=xxx (where xxx is the connection # from that IP) so you get the complete connection from start to finish.
- Look at the BIND lines to see what that workstation is binding as.
- Look at the SRCH lines, to see what basedn and filter is being used.
- Look at the result line (right after the SRCH line) to see what the results are (though you'll probably just see err=32, which is no such object). If there are multiple SRCH lines, check each one.
- Check the ACI's set on your suffix - in console, click on the
Directory tab then right click on the top entry in your tree, and select "set permissions" (something like that - doing this from memory). Make sure the appropriate access is set.
You may have to look throughout your tree for aci's to be sure you find everything.
(ldapsearch -D cn=directory manager -w - ... -b "your basedn" "(aci=*)" "aci" to find 'em all.)
I'm a little late to this forum, but I'm posting my fix anyway since I had the exact same problem and Google brought me here first!
I was also seeing the following error in /var/adm/messages:
After a couple hours of digging and being unable to reproduce the error with any reliability, I discovered the solution. This is the error that's created when someone logs in with an incorrect password! It's perfectly normal!
Oct 27 14:48:19 vpd1th2no sshd: [ID 293258 auth.error] libsldap: Status: 49 Mesg: openConnection: simple bind failed - Invalid credentials
Message was edited by:
Can anyone pls help? this problem is still there.IS there anything to be done with PAM?
I've been struggling with the same error:
I can't get my ldapclient works with AD authentication. I doubled check with binding account is correct. I'm successfully to get the kerberos working by using kinit command, but this error keep showing up in my /var/adm/messages when I try to use command getent passwd aduser. Any suggestions? Thanks
solaris10-test nscd: [ID2933258 user.error] libsldap: Status 49 Mesg: openConnection: simple bind failed - Invalid credentials
This is bind dn authentication problem
ldapsearch -v -h 196.x.x.x -b OU=users,OU=dotcom,DC=pankajgautam,DC=com -D'cn=$pankaj,ou=ServiceAccounts,dc=pankajgautam,dc=com' -w 'xxxxx' "samAccountName=pg"
ldapsearch -v -h 196.x.x.x -b OU=users,OU=dotcom,DC=pankajgautam,DC=com -D "cn=$pankaj,ou=ServiceAccounts,dc=pankajgautam,dc=com" -w 'xxxxx' "samAccountName=pg"
It needs the exact the bind dn user address from the AD/LDAP
and also watch the double quotes
Yes I saw the same thing on my hosts. In my case, it was telnet. When a login via telnet entered an incorrect password, the message appeared in the log.