why the log say pam_unix(sshd:auth): authentication failure but the login works fine? or can anyone tell me how can I fix this.
Jun 27 09:46:31 [localhost] sshd[16341]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.56.1 user=ope_fptsoft01
Jun 27 09:46:31 [localhost] sshd[16341]: Accepted password for ope_fptsoft01 from 192.168.56.1 port 55087 ssh2
Jun 27 09:46:31 [localhost] sshd[16341]: pam_unix(sshd:session): session opened for user ope_fptsoft01 by (uid=0)
My system-auth:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth sufficient pam_unix.so
auth sufficient pam_ldap.so minimum_uid=1000 use_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok use_authtok
password sufficient pam_ldap.so minimum_uid=1000 try_first_pass
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session optional pam_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so minimum_uid=1000
Your PAM stack configuration lists two different modules to be sufficient for authentication:
auth sufficient pam_unix.so
auth sufficient pam_ldap.so minimum_uid=1000 use_first_pass
So first the user is tried via pam_unix.so which fails because it's likely a remote user in a LDAP user management. So the user probably was successfully authenticated via pam_ldap.so.
Normally one would set option try_first_pass:
auth sufficient pam_unix.so try_first_pass
auth sufficient pam_ldap.so minimum_uid=1000 use_first_pass
See also: pam_unix(8)
My solution is:
auth sufficient pam_unix.so try_first_pass
auth sufficient pam_ldap.so
Related
I have a working LDAP server. Next added password policy to LDAP server. My password ldif looks like this:
dn: cn=MyPolicy,ou=Policies,dc=XXX,dc=XXXX
cn: MyPolicy
objectClass: pwdPolicy
#objectClass: pwdPolicyChecker
objectClass: device
objectClass: top
pwdAttribute: 2.5.4.35
#pwdAttribute: userPassword
pwdMaxAge: 7862400
pwdExpireWarning: 6048000
pwdInHistory: 3
pwdCheckQuality: 2
pwdMinLength: 7
pwdMaxFailure: 3
pwdLockout: TRUE
pwdLockoutDuration: 300
pwdGraceAuthNLimit: 0
pwdFailureCountInterval: 0
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE
pwdReset: FALSE
it is successfully added to my LDAP server. But only Lock out and Lock out duration is working. Password minimum length is not working.
pam configuration
Server side configuration
pam.d/common-auth
auth [success=1 default=ignore] pam_ldap.so nullok_secure try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
pam.d/common-account
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
pam.d/common-password
password [success=1 default=ignore] pam_unix.so obscure sha512 minlen=8
password requisite pam_deny.so
password required pam_permit.so
Client side configuration
pam.d/common-auth
auth [success=2 default=ignore] pam_unix.so null_secure try_first_pass
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
pam.d/common-account
account [success=2 new_authtok_reqd=done default=ignore] pam_ldap.so
account [success=1 default=ignore] pam_unix.so
account needs pam_deny.so
account required pam_permit.so
pam.d/common-password
password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 user_unknown=ignore default=die] pam_ldap.so try_first_pass
password requisite pam_deny.so
password required pam_permit.so
ldap.conf
pam_lookup_policy yes
Can you please let me know where I am gone wrong.
pwdLockout: TRUE
pwdLockoutDuration: 300
These attributes are used on failed bind attempts to lock an account
pwdMinLength: 7
This attribute is only checked when a user (except manager DN) performs a modify password operation on his userPassword attribute. It will not lock already created accounts which do not satisfy this rule.
EDIT :
Considering your different comments, try to modify the line in your file /etc/ldap.conf :
From :
pam_password crypt
To :
pam_password exop
It will modify the password using the extended operation modifypassword and so should trigger the password policy.
If you're using OpenLDAP, the password policy overlay is completely bypassed by the ManagerDN. You should never use this yourself: it is only for the OpenLDAP server itself. You need to use another, less privileged but sufficiently priviledged, LDAP account for performing password modifications: preferably, the user's own account.
I am using openldap 2.4. I have configured it with following configuration.
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/HFSchema.schema
include /etc/ldap/schema/ppolicy.schema
pidfile /var/run/slapd/slapd.pid
modulepath /usr/lib/ldap
moduleload back_hdb.la
moduleload ppolicy.la
database hdb
suffix "dc=example,dc=com"
rootdn "cn=admin,dc=example,dc=com"
rootpw {SSHA}xzW0DfNFHahvm/C68ZR4YvbZGFQJjfz5
overlay ppolicy
ppolicy_default "cn=DefaultPwdPolicy,ou=Policies,dc=example,dc=com"
ppolicy_use_lockout
ppolicy_hash_cleartext
Also I added default password policy
# DefaultPwdPolicy, Policies, example.com
dn: cn=DefaultPwdPolicy,ou=Policies,dc=example,dc=com
cn: DefaultPwdPolicy
pwdAttribute: 2.5.4.35
objectClass: pwdPolicy
objectClass: top
objectClass: device
pwdAllowUserChange: TRUE
pwdMaxAge: 7776000
pwdInHistory: 5
pwdCheckQuality: 2
pwdMinLength: 8
pwdExpireWarning: 432000
pwdLockoutDuration: 900
pwdMaxFailure: 3
pwdMustChange: TRUE
pwdSafeModify: TRUE
pwdLockout: TRUE
But still admin is able to create users without these constraints. How will I confirm if my ppolicy overlay is working? How can I test if these constraint are actually been applied.?
The only user that is free from the password policy constraints is the internal rootdn user. You shouldn't use that yourself for anything. It is the user that slapd itself uses to update the DIT. You should define another admin user, in the DIT, with the necessary permissions. Using the rootdn user for admin tasks will bypass every constraint known to man.
To use the ppolicy fully, you have to use the password policy request control and check for the corresponding response control in your code so you can discover impending expiry, grace periods, etc.
You can test password policy with ldap* commands (OpenLDAP LDAP clients), which allow to use LDAP controls.
You must know a valid DN and a password (not rootdn, which override password policy).
For example:
clement#ader-xps:~$ ldapwhoami -x -H ldap://localhost -D uid=coudot,ou=users,dc=example,dc=com -W -e ppolicy
Enter LDAP Password:
ldap_bind: Invalid credentials (49); Account locked
I've setup a linux machine (debian 6.0.7) with ldap authentication with the following configurations:
/etc/nsswitch.conf
passwd: compat ldap [NOTFOUND=return UNAVAIL=continue] db
group: compat ldap [NOTFOUND=return UNAVAIL=continue] db
shadow: compat ldap
/etc/pam.d/common-account
# here are the per-package modules (the "Primary" block)
account [user_unknown=ignore authinfo_unavail=ignore default=ok] pam_unix.so
account [success=ok user_unknown=ignore authinfo_unavail=ignore default=ignore] pam_succeed_if.so uid < 1000 debug
account [success=done default=ignore authinfo_unavail=1] pam_ldap.so debug
# here's the fallback if no module succeeds
account requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
/etc/pam.d/common-auth
# here are the per-package modules (the "Primary" block)
auth [success=done default=ignore] pam_unix.so nullok_secure
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth requisite pam_succeed_if.so gid >= 1000 quiet
auth requisite pam_succeed_if.so user notingroup root
auth requisite pam_succeed_if.so user notingroup wheel
auth [success=3 default=2 authinfo_unavail=ignore] pam_ldap.so use_first_pass
auth [success=2 default=ignore] pam_ccreds.so minimum_uid=1000 action=validate use_first_pass
auth [default=ignore] pam_ccreds.so minimum_uid=1000 action=update
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_ccreds.so minimum_uid=1000 action=store
# end of pam-auth-update config
/etc/pam.d/common-password
# here are the per-package modules (the "Primary" block)
password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 user_unknown=ignore default=die authinfo_unavail=ignore] pam_ldap.so try_first_pass
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
password optional pam_gnome_keyring.so
# end of pam-auth-update config
/etc/pam.d/common-session
# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session required pam_mkhomedir.so skel=/etc/skel umask=0022
session optional pam_ldap.so
# end of pam-auth-update config
in common-account I had to jump to pam_permit if ldap server is unavailable otherwise users with cached credentials can't authenticate, but I think this is not a good idea.
I'm also running nss_updatedb ldap to cache passwd and groups.
Everything is working fine, even offline authentication. The problem is when I disable a user on ldap (setting shadowexpire to 1). When the machine is online authentication system notify that the account is disabled but when the machine is offline a disabled user can login using cached credentials. I believe it's because shadow infos aren't cached.
Is it a way to cache shadow informations about disabled users so they can't log in even when the machine is offline?
pam_ccreds README says this isn't currently supported. You could reset the user's password instead of using shadowexpire.
Thank you for sharing your config! I changed /etc/pam.d/common-account from
account [user_unknown=ignore authinfo_unavail=ignore default=ok] pam_unix.so
to
account [success=done user_unknown=ignore authinfo_unavail=ignore default=ok] pam_unix.so
The problem was that when the LDAP server was not available a local user was turned down even with a good password. success=done terminates the chain once pam_unix.so says it is ok.
I am trying to use mod_authz_ldap for user authentication. Have a strange LDAP setup where, we have to bind to the LDAP directory as
uid=user,o=organisation
then query
cn=xxx,o=organisation
to get the credentials of the user. The following configuration actually works, except that it attempts to use the credentials of the user logging in to bind to the LDAP directory, which needless to say fails.
To validate this, I tried to authenticate to the application as our LDAP bind user and the authentication succeeds.
<Location />
AuthType Basic
AuthName "My LDAP authenticated app"
AuthzLDAPLogLevel debug
AuthBasicProvider ldap
AuthBasicAuthoritative off
AuthzLDAPAuthoritative off
AuthzLDAPBindPassword bindpass
AuthzLDAPBindDN "uid=binduser,o=my.edu.au"
AuthzLDAPMethod ldap
AuthzLDAPServer ldapdevel.my.edu.au
AuthzLDAPUserBase o=my.edu.au
AuthzLDAPUserKey cn
AuthzLDAPUserScope base
AuthLDAPRemoteUserAttribute cn
Require valid-user
</Location>
Apache error log to demonstrate that mod_authz_ldap is attempting to bind as the user attempt to authenticate agains the app:
[Fri Sep 07 14:14:27 2012] [error] [client xxx.xxx.xxx.xxx] [15628] bind as cn=devraj,l=X,ou=Students,o=my.edu.au failed: 49
[Fri Sep 07 14:14:27 2012] [error] [client xxx.xxx.xxx.xxx] [15628] basic LDAP authentication of user 'devraj' failed
[Fri Sep 07 14:14:27 2012] [error] [client xxx.xxx.xxx.xxx] access to / failed, reason: verification of user id 'devraj' not configured
Also if I provide incorrect bind credentials mod_authz_ldap complains about not being able to bind as the bind user. This suggests that it tries to bind as the bind user, but also binds as the authenticating user.
My Question, what am I doing wrong that's causing mod_auz_ldap to use the users credentials to bind to the LDAP directory?
Thanks for your time.
Why is AuthzLDAPBindDN "uid=binduser,o=my.edu.au"?
Then you show AuthzLDAPUserKey cn.
The "uid=binduser,o=my.edu.au" should typically, be a valid user from LDAP and usually a service account.
Then the AuthzLDAPUserKey cn would represent the RDN (Relative Distinguished Name) attribute of users in LDAP. It would be non-typical for you to have a user uid=binduser and other users to be like: cn=devraj.
Does uid=binduser,o=my.edu.au exist?
Does the user cn=devraj,l=X,ou=Students,o=my.edu.au exist?
(or is it: uid=devraj,l=X,ou=Students,o=my.edu.au)
-jim
it attempts to use the credentials of the user logging in to bind to the LDAP directory, which needless to say fails
Why 'needless to say'? And why does it fail at all? This is exactly what it is supposed to do. Normally you should be searching the directory for the user, possibly using a system account to do so, then binding as the found user with his credentials. If that succeeds, authentication is complete. If your LDAP isn't set up to support that, it is set up wrongly.
I have set up an ldap authentication using the following configuration. I just need to user to authenticate to the LDAP data store, then have their session get an authentication token. From reading the docs, this is what I am thinking is supposed to happen:
Authenticate as the manager, find the users full dn based on search criteria
Attempt to bind as the user (using their full dn) and the provided password
The logs dont seem to give enough information as to why this is failing. It just says invalid credentials - when I know they are valid. My thoughts are one of the following is happening:
The users full DN is not being found, and they are just being authenticated with the username
It is trying to do a password compare, vs actually trying to bind to the directory
Configuration:
<ldap-server
url="ldap://adapps.company.com:389/dc=company,dc=com"
manager-dn="cn=fulluserdn,dc=company,dc=com"
manager-password="password"/>
<ldap-user-service user-search-base="" user-search-filter="(samaccountname={0})"/>
<authentication-manager>
<ldap-authentication-provider user-search-filter="(samaccountname={0})" user-search-base="dc=company,dc=com"/>
</authentication-manager>
Error logs:
[DEBUG,FilterBasedLdapUserSearch] Searching for user 'test', with user search [ searchFilter: '(samaccountname={0})', searchBase: 'dc=company,dc=com', scope: subtree, searchTimeLimit: 0, derefLinkFlag: false ]
[DEBUG,AbstractContextSource] Got Ldap context on server 'ldap://adapps.company.com:389/dc=company,dc=com'
[INFO,SpringSecurityLdapTemplate] Ignoring PartialResultException
[DEBUG,XmlWebApplicationContext] Publishing event in Root WebApplicationContext: org.springframework.security.authentication.event.AuthenticationFailureBadCredentialsEvent[source=org.springframework.security.authentication.UsernamePasswordAuthenticationToken#488b5f0b: Principal: test; Password: [PROTECTED]; Authenticated: false; Details: org.springframework.security.web.authentication.WebAuthenticationDetails#fffd148a: RemoteIpAddress: 127.0.0.1; SessionId: 0718B7EED3F930C63C03DA97C4344CBD; Not granted any authorities]
[DEBUG,UsernamePasswordAuthenticationFilter] Authentication request failed: org.springframework.security.authentication.BadCredentialsException: Bad credentials
[DEBUG,UsernamePasswordAuthenticationFilter] Updated SecurityContextHolder to contain null Authentication
[DEBUG,UsernamePasswordAuthenticationFilter] Delegating to authentication failure handlerorg.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler#395158
[DEBUG,TokenBasedRememberMeServices] Interactive login attempt was unsuccessful.
[DEBUG,TokenBasedRememberMeServices] Cancelling cookie
The problem was teat the LDAP server was running on a different port, but the normal port was still open.