Dear list members,
i have installed a CentOS 7 x86_64 system. I want to let users authenticate over our ldap server. This seems to be working. ldap-username and ldap-passwords are accepted for the users configured in the ldap server. No problem.
Now i want to restrict the access to users who have my centos-machine in their ldap host attribute.
My problem is, that this host attribute seems to be ignored. Any ldap user, independent from the host attribute, still can login in.
What could be the reason? (googling around did not lead me to a solution).
The cache is already flushed.
Here is my configuration:
/etc/openldap/ldap.conf contains the line: ------------------------------------------ pam_check_host_attr yes
/etc/sssd/sssd.conf: -------------------- [sssd] config_file_version = 2 services = nss, pam, autofs domains = default # SSSD will not start if you do not configure any domains. # Add new domain configurations as [domain/<NAME>] sections, and # then add the list of domains (in the order you want them to be # queried) to the "domains" attribute below and uncomment it. # domains = LDAP
[nss] filter_groups = root filter_users = root
[pam]
[domain/default] ldap_uri = ldap://myldapserver.mydomain ldap_search_base = o=XXXX ldap_schema = rfc2307bis id_provider = ldap ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid ldap_id_use_start_tls = True enumerate = False cache_credentials = False ldap_tls_cacertdir = /etc/openldap/cacerts/ chpass_provider = ldap auth_provider = ldap ldap_tls_reqcert = never ldap_user_search_base = ou=YYYY,o=XXXX ldap_group_search_base = ou=YYYY,o=XXXX
access_provider = ldap ldap_access_filter = memberOf=ou=YYYY,o=XXXX ldap_access_order = host
/etc/pam.d/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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success #auth sufficient pam_sss.so use_first_pass auth required pam_sss.so use_first_pass auth required pam_deny.so auth sufficient pam_unix.so try_first_pass
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.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 md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
in /etc/nscd.conf: ------------------ enable-cache passwd no enable-cache group no enable-cache hosts no enable-cache services no enable-cache netgroup no
/etc/nsswitch.conf: ................... passwd: files sss ldap shadow: files sss ldap group: files sss ldap #initgroups: files
#hosts: db files nisplus nis dns hosts: files dns
# Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files
bootparams: nisplus [NOTFOUND=return] files
ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss
netgroup: files sss ldap
publickey: nisplus
automount: files sss ldap aliases: files nisplus
The ldap attributes of the user who can login, but should not: --------------------------------------------------------------
dn: uid=USER1,ou=XXXX,o=YYYY accountStatus: active objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: shadowAccount objectClass: ibm-auxAccount objectClass: qmailUser objectClass: sambaSamAccount uid: USER1 uidNumber: **** shadowFlag: 0 shadowInactive: -1 gidNumber: *** shadowMin: -1 shadowMax: 999999 homeDirectory: /home/USER1 sn: USER1 mail: USER1 at my.doma.in mailHost: lmtp:unix:/var/lib/imap/socket/lmtp shadowWarning: 7 sambaSID: ***************************************** shadowExpire: -1 mailAlternateAddress: USER1a cn: surname lastname gecos: surname lastname loginShell: /bin/bash host: another-node
What information is still missing?
Any hint is welcome.
Thank you in advance, ulrich
Hi,
On Tue, May 5, 2015 at 3:32 PM, Ulrich Hiller hiller@mpia-hd.mpg.de wrote:
Dear list members,
i have installed a CentOS 7 x86_64 system. I want to let users authenticate over our ldap server. This seems to be working. ldap-username and ldap-passwords are accepted for the users configured in the ldap server. No problem.
Now i want to restrict the access to users who have my centos-machine in their ldap host attribute.
My problem is, that this host attribute seems to be ignored. Any ldap user, independent from the host attribute, still can login in.
What could be the reason? (googling around did not lead me to a solution).
Try to set 'pam_check_host_attr yes' in /etc/ldap.conf .
--Regards Ashishkumar S. Yadav
Hi,
'pam_check_host_attr yes' is in /etc/openldap/ldap.conf. /etc/ldap.conf is a softlink to that file.
But still the host attribute is ignored.
With kind regards, ulrich
On 05/05/2015 12:32 PM, Ashish Yadav wrote:
Hi,
On Tue, May 5, 2015 at 3:32 PM, Ulrich Hiller hiller@mpia-hd.mpg.de wrote:
Dear list members,
i have installed a CentOS 7 x86_64 system. I want to let users authenticate over our ldap server. This seems to be working. ldap-username and ldap-passwords are accepted for the users configured in the ldap server. No problem.
Now i want to restrict the access to users who have my centos-machine in their ldap host attribute.
My problem is, that this host attribute seems to be ignored. Any ldap user, independent from the host attribute, still can login in.
What could be the reason? (googling around did not lead me to a solution).
Try to set 'pam_check_host_attr yes' in /etc/ldap.conf .
--Regards Ashishkumar S. Yadav _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
unfortunately i got a syntax error with this method "ldap_access_filter = host='HOSTNAME' " and sssd did not restart. i added the line ldap_user_authorized_host = host without success
I have to admit that i do not have any idea where to look for the problem:
- is it sssd? I have the version 1.12.2 - is it pam (something in /etc/pam.d) - is is ldap (etc/ldap.conf)? - is it /etc/nsswitch.conf?
The auhtentication with username and password works. Only the host attribute is the problem.
We have several opensuse boxes of different OS versions running, and ther it works very good. So i do not thing there is a problem on the ldap server.
With kind regards, ulrich
On 05/05/2015 03:43 PM, Kai Grunau wrote:
hi,
On 05/05/2015 12:02 PM, Ulrich Hiller wrote:
access_provider = ldap ldap_access_filter = memberOf=ou=YYYY,o=XXXX ldap_access_order = host
try instead of "ldap_access_order = host" parameter "ldap_access_filter = host='HOSTNAME' " to use
regards, Kai
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ulrich Hiller wrote:
unfortunately i got a syntax error with this method "ldap_access_filter = host='HOSTNAME' " and sssd did not restart. i added the line ldap_user_authorized_host = host without success
I have to admit that i do not have any idea where to look for the problem:
<snip> google centos "ldap_access_filter" host
and about the first hit is this thread, which may help you.
http://serverfault.com/questions/564255/sssd-ignoring-ldap-access-filter
mark
I already have seen this page, but it does not help me. But anyway, thanks a lot for your help.
With kind regards, ulrich
On 05/05/2015 05:47 PM, m.roth@5-cent.us wrote:
Ulrich Hiller wrote:
unfortunately i got a syntax error with this method "ldap_access_filter = host='HOSTNAME' " and sssd did not restart. i added the line ldap_user_authorized_host = host without success
I have to admit that i do not have any idea where to look for the problem:
<snip> google centos "ldap_access_filter" host
and about the first hit is this thread, which may help you.
http://serverfault.com/questions/564255/sssd-ignoring-ldap-access-filter
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 05/05/2015 03:02 AM, Ulrich Hiller wrote:
/etc/openldap/ldap.conf contains the line:
pam_check_host_attr yes
/etc/openldap/ldap.conf is the configuration file for openldap clients. It is not used for system authentication or name service.
'pam_check_host_attr yes' is in /etc/openldap/ldap.conf. /etc/ldap.conf is a softlink to that file.
Those two files have completely different syntax and are used by different software. Don't symlink them.
/etc/sssd/sssd.conf:
If you're using sssd, then you're not using (or shouldn't be using) the PADL nss module. In that case, /etc/ldap.conf shouldn't even be present.
[domain/default] access_provider = ldap ldap_access_filter = memberOf=ou=YYYY,o=XXXX ldap_access_order = host
ldap_access_filter should be an LDAP filter, not an OU. However, it's only used when ldap_access_order=filter. When using ldap_access_order=host, it should not be present.
in /etc/nscd.conf:
nscd is also not used when using sssd.
/etc/nsswitch.conf: ................... passwd: files sss ldap shadow: files sss ldap group: files sss ldap
This is wrong. Don't use sss and ldap together. It's redundant. At best it will cause performance problems.
Get rid of the ldap module and see if the system starts working correctly with just sssd. It's possible that right now sssd is correctly filtering users, but the PADL ldap module is providing them.
On 05/05/2015 06:47 PM, Gordon Messmer wrote:
On 05/05/2015 03:02 AM, Ulrich Hiller wrote:
/etc/openldap/ldap.conf contains the line:
pam_check_host_attr yes
/etc/openldap/ldap.conf is the configuration file for openldap clients. It is not used for system authentication or name service.
'pam_check_host_attr yes' is in /etc/openldap/ldap.conf. /etc/ldap.conf is a softlink to that file.
Those two files have completely different syntax and are used by different software. Don't symlink them.
i deleted the link now. /etc/ldap.conf was not present before. I gave openldap
/etc/sssd/sssd.conf:
If you're using sssd, then you're not using (or shouldn't be using) the PADL nss module. In that case, /etc/ldap.conf shouldn't even be present.
[domain/default] access_provider = ldap ldap_access_filter = memberOf=ou=YYYY,o=XXXX ldap_access_order = host
ldap_access_filter should be an LDAP filter, not an OU. However, it's only used when ldap_access_order=filter. When using ldap_access_order=host, it should not be present.
ldap_access_filter is now commented out.
in /etc/nscd.conf:
nscd is also not used when using sssd.
/etc/nsswitch.conf: ................... passwd: files sss ldap shadow: files sss ldap group: files sss ldap
This is wrong. Don't use sss and ldap together. It's redundant. At best it will cause performance problems.
Get rid of the ldap module and see if the system starts working correctly with just sssd. It's possible that right now sssd is correctly filtering users, but the PADL ldap module is providing them.
This was a good hint (i should have got the idea myself). Now i set passwd: files ldap shadow: files ldap group: files ldap
and got "pam_unix(sshd:auth): check pass; user unknown" the same when i set in sssd.conf services = pam
So, does it mean only the NSS is providing the ldap user information, and sssd cannot read the pam information? So pam is not set up correctly?
I am confused about what to do now. Do i have to configure anything else in /etc/pam.d apart from system-auth?
With kind regards, ulrich
Hi,
I am confused about what to do now.
Do i have to configure anything else in /etc/pam.d apart from system-auth?
IMO, you have to configure sssd.conf properly.
Please add "ldap_user_authorized_host = host" in your sssd.conf which you have not configured. After that please check again.
For more information, please refer below link.
https://lists.fedorahosted.org/pipermail/sssd-users/2015-May/003001.html
--Regards Ashishkumar S. Yadav
Hi,
added, but no success. My sssd.conf looks now so: [sssd] config_file_version = 2 services = nss,pam domains = default # SSSD will not start if you do not configure any domains. # Add new domain configurations as [domain/<NAME>] sections, and # then add the list of domains (in the order you want them to be # queried) to the "domains" attribute below and uncomment it.
[nss] filter_groups = root filter_users = root
[pam]
# Section created by YaST [domain/default] ldap_uri = ldap://ldap.mpia-hd.mpg.de ldap_search_base = o=mpia ldap_schema = rfc2307bis id_provider = ldap ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid ldap_id_use_start_tls = True enumerate = False cache_credentials = False ldap_tls_cacertdir = /etc/ssl/certs chpass_provider = ldap auth_provider = ldap ldap_tls_reqcert = never ldap_user_search_base = ou=people,o=mpia ldap_group_search_base = ou=group,o=mpia
access_provider = ldap #ldap_access_filter = memberOf=ou=people,o=mpia ldap_access_order = host ldap_user_authorized_host = host
and my nsswitch,conf: passwd: files ldap shadow: files ldap group: files ldap #initgroups: files #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss ldap publickey: nisplus automount: files sss ldap aliases: files nisplus
I get a "user unknown". With passwd: files sss ldap shadow: files sss ldap group: files sss ldap in nsswitch.conf all ldap users can login, independently from the host attribute.
With kind regards, ulrich
On 05/05/2015 08:58 PM, Ashish Yadav wrote:
Hi,
I am confused about what to do now.
Do i have to configure anything else in /etc/pam.d apart from system-auth?
IMO, you have to configure sssd.conf properly.
Please add "ldap_user_authorized_host = host" in your sssd.conf which you have not configured. After that please check again.
For more information, please refer below link.
https://lists.fedorahosted.org/pipermail/sssd-users/2015-May/003001.html
--Regards Ashishkumar S. Yadav _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 05/05/2015 11:14 AM, Ulrich Hiller wrote:
On 05/05/2015 06:47 PM, Gordon Messmer wrote:
This is wrong. Don't use sss and ldap together. It's redundant. At best it will cause performance problems.
Get rid of the ldap module and see if the system starts working correctly with just sssd. It's possible that right now sssd is correctly filtering users, but the PADL ldap module is providing them.
This was a good hint (i should have got the idea myself). Now i set passwd: files ldap shadow: files ldap group: files ldap
That's exactly the opposite of what I suggested. Your system is now using the deprecated PADL ldap module for name service instead of sssd.
You should probably remove nscd and nss-pam-ldapd from your system entirely. They're deprecated, and they're going to waste your time.
and got "pam_unix(sshd:auth): check pass; user unknown"
That seems consistent with having "ldap" in nsswitch.conf and no /etc/ldap.conf.
Don't use "ldap". Use "sss".
So, does it mean only the NSS is providing the ldap user information, and sssd cannot read the pam information? So pam is not set up correctly?
That's a confusing question, so let me explain the stack a little.
At one end you have your applications. Everything that needs to resolve user names, groups, hosts, services, etc is here. For example, "ls". "ls" reads directories and stats files, those files have numeric user and group IDs, which need to be resolved to names.
In the middle you have glibc and its "nss" API. "nss" provides a single interface to applications for resolving names and numbers for the types defined in nsswitch.conf.
At the other end of the stack you have nss modules. These include the "unix" module which reads files in /etc, the deprecated LDAP module from PADL, and the sss module that's part of sssd.
(sssd extends the stack a little bit. it provides one interface to nss, and has its own modules to resolve names through LDAP and other directories)
PAM is completely separate from all of that. PAM provides authentication services. It's a completely different interface from resolving names and numbers.
So, right now it sounds like you have the system configured to read information from the "ldap" module, but that module needs /etc/ldap.conf. You should be using the "sss" module in nsswitch.conf instead.
I am confused about what to do now. Do i have to configure anything else in /etc/pam.d apart from system-auth?
You probably shouldn't ever touch the files in /etc/pam.d.
Thanks a lot for the explanation. I have confused some things while crawling through the manuals.
Now i have removed the 'ldap' from the /etc/nsswitch.conf. Now it looks like this:
passwd: files sss shadow: files sss group: files sss hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files sss aliases: files nisplu
My /etc/openldap/ldap.conf is this: TLS_CACERTDIR /etc/openldap/cacerts/ SASL_NOCANON on URI ldap://ldap.mydomain.tld BASE o=XXX
The sssd.conf is this: [sssd] config_file_version = 2 services = nss, pam, autofs domains = default
[nss] filter_groups = root filter_users = root
[pam]
[domain/default] ldap_uri = ldap://ldap.mydomain.tld ldap_search_base = o=XXX ldap_schema = rfc2307bis id_provider = ldap ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid ldap_id_use_start_tls = True enumerate = False cache_credentials = False ldap_tls_cacertdir = /etc/ssl/certs chpass_provider = ldap auth_provider = ldap ldap_tls_reqcert = never ldap_user_search_base = ou=YYY,o=XXX ldap_group_search_base = ou=YYY,o=XXX
access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host
autofs_provider = ldap krb5_realm = # [autofs]
When i stop the sssd deamon, no login at all is possible. But when i start sssd, again login is successful, independendly from what i write into ldap_access_order and ldap_user_authorized_host (if i don't commit syntax errors). I also tried with ldap_access_filter and inserting "pam_check_host_attr yes" into ldap.conf. Still the same: When username and password are correct, the host atribute is ignored.
Is there another config file i have to edit?
With kind regards, ulrich
On 05/05/2015 11:43 PM, Gordon Messmer wrote:
On 05/05/2015 11:14 AM, Ulrich Hiller wrote:
On 05/05/2015 06:47 PM, Gordon Messmer wrote:
This is wrong. Don't use sss and ldap together. It's redundant. At best it will cause performance problems.
Get rid of the ldap module and see if the system starts working correctly with just sssd. It's possible that right now sssd is correctly filtering users, but the PADL ldap module is providing them.
This was a good hint (i should have got the idea myself). Now i set passwd: files ldap shadow: files ldap group: files ldap
That's exactly the opposite of what I suggested. Your system is now using the deprecated PADL ldap module for name service instead of sssd.
You should probably remove nscd and nss-pam-ldapd from your system entirely. They're deprecated, and they're going to waste your time.
and got "pam_unix(sshd:auth): check pass; user unknown"
That seems consistent with having "ldap" in nsswitch.conf and no /etc/ldap.conf.
Don't use "ldap". Use "sss".
So, does it mean only the NSS is providing the ldap user information, and sssd cannot read the pam information? So pam is not set up correctly?
That's a confusing question, so let me explain the stack a little.
At one end you have your applications. Everything that needs to resolve user names, groups, hosts, services, etc is here. For example, "ls". "ls" reads directories and stats files, those files have numeric user and group IDs, which need to be resolved to names.
In the middle you have glibc and its "nss" API. "nss" provides a single interface to applications for resolving names and numbers for the types defined in nsswitch.conf.
At the other end of the stack you have nss modules. These include the "unix" module which reads files in /etc, the deprecated LDAP module from PADL, and the sss module that's part of sssd.
(sssd extends the stack a little bit. it provides one interface to nss, and has its own modules to resolve names through LDAP and other directories)
PAM is completely separate from all of that. PAM provides authentication services. It's a completely different interface from resolving names and numbers.
So, right now it sounds like you have the system configured to read information from the "ldap" module, but that module needs /etc/ldap.conf. You should be using the "sss" module in nsswitch.conf instead.
I am confused about what to do now. Do i have to configure anything else in /etc/pam.d apart from system-auth?
You probably shouldn't ever touch the files in /etc/pam.d.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 05/06/2015 07:24 AM, Ulrich Hiller wrote:
Now i have removed the 'ldap' from the /etc/nsswitch.conf. Now it looks like this:
Looks good.
My /etc/openldap/ldap.conf is this:
OK, but that file isn't used for name service or authentication. Mostly just the openldap tools (ldapsearch, ldapadd, ldapmodify).
The sssd.conf is this:
...
[nss] filter_groups = root filter_users = root
nitpick: those are the defaults. Probably don't need to set them.
[domain/default] ldap_id_use_start_tls = True ldap_tls_cacertdir = /etc/ssl/certs ldap_tls_reqcert = never
Not sure about that setting. "allow" is probably what you want if you're using starttls.
access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host
...
When i stop the sssd deamon, no login at all is possible.
OK. Remember that previously you had both sssd and ldap configured to provide user information.
You'll want to watch the logs for more information.
Start by determining whether the problem is in the name service or authentication step. Use "id <user>" or "getent passwd <user>" to determine whether user information is available through sssd. If it is not, then you probably want to start paring out settings that you added (assuming that you started with a file written by authconfig) until that's working.
If user data is available, then start looking at your pam configuration. It looks like you made some changes there, and not all of them make sense. In the auth stack, you're calling pam_unix.so twice. Remove the last one. You've also marked pam_sss.so as required instead of sufficient, which is definitely wrong. On success of a "sufficient" module, processing stops. On success of a "required" module, processing will continue, and will reach pam_deny.so. See the man page for pam.conf for more information.
Thanks a lot for looking over the config.
I am at the topic "user data is available"
id <username> and getent passwd and ldapsearch -x -b "ou=XXX,o=YYY" uid=<username>
give the correct results ldapsearch gives also the correct host attribute i have set in the ldap server.
Regarding the manpage of sssd.conf the lines access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host should be correct.
login with the wrong password gives a denied login. login with the correct password always works.
This is my sitution since the begin of my thread.
When i login from a "wrong" host which is different than the one in the host attribute of the ldap, i expect a message like the one from my opensuse boxes where it works:
opensuse: sshd[7926]: pam_sss(sshd:account): Access denied for user
username>: 6 (Permission denied)
But instead i get centos: sshd[7929]: pam_unix(sshd:session): session opened for user <username> and i am in.
[ ssh'ing and login locally at the console give the same results ]
So, maybe it is a pam problem.
Comparing the pam.d of my opensuse boxes with my centos box i see common-* files which are inluced, e.g. in the sshd file. They do not exist in centos. Instead i have there the system-auth where the common files should be combined. Fiddling around with the contence of my opensuse commen-* in my centos box's system-auth i did not get further.
I have installed on centos: fprintd-pam-0.5.0-4.0.el7_0.x86_64 pam-1.1.8-12.el7.x86_64 gnome-keyring-pam-3.8.2-10.el7.x86_64 pam_krb5-2.4.8-4.el7.x86_64
Are you sure i do not need nss-pam-ldapd? Googling around i have read something about a /etc/nslcd.conf which comes with this package. Is that needed?
On my opensuse i have much more: gnome-keyring-pam-3.10.1-6.1.x86_64 pam-config-0.86-2.1.2.x86_64 pam-1.1.8-6.1.x86_64 gnome-keyring-pam-32bit-3.10.1-6.1.x86_64 pam-modules-12.1-20.1.2.x86_64 pam_ldap-186-6.1.3.x86_64 pam-devel-1.1.8-6.1.x86_64 pam-32bit-1.1.8-6.1.x86_64 pam-modules-32bit-12.1-20.1.2.x86_64 pam_ldap-32bit-186-6.1.3.x86_64
With kind regards and sorry for the stupid newbie's questions, ulrich
On 05/06/2015 07:02 PM, Gordon Messmer wrote:
On 05/06/2015 07:24 AM, Ulrich Hiller wrote:
Now i have removed the 'ldap' from the /etc/nsswitch.conf. Now it looks like this:
Looks good.
My /etc/openldap/ldap.conf is this:
OK, but that file isn't used for name service or authentication. Mostly just the openldap tools (ldapsearch, ldapadd, ldapmodify).
The sssd.conf is this:
...
[nss] filter_groups = root filter_users = root
nitpick: those are the defaults. Probably don't need to set them.
[domain/default] ldap_id_use_start_tls = True ldap_tls_cacertdir = /etc/ssl/certs ldap_tls_reqcert = never
Not sure about that setting. "allow" is probably what you want if you're using starttls.
access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host
...
When i stop the sssd deamon, no login at all is possible.
OK. Remember that previously you had both sssd and ldap configured to provide user information.
You'll want to watch the logs for more information.
Start by determining whether the problem is in the name service or authentication step. Use "id <user>" or "getent passwd <user>" to determine whether user information is available through sssd. If it is not, then you probably want to start paring out settings that you added (assuming that you started with a file written by authconfig) until that's working.
If user data is available, then start looking at your pam configuration. It looks like you made some changes there, and not all of them make sense. In the auth stack, you're calling pam_unix.so twice. Remove the last one. You've also marked pam_sss.so as required instead of sufficient, which is definitely wrong. On success of a "sufficient" module, processing stops. On success of a "required" module, processing will continue, and will reach pam_deny.so. See the man page for pam.conf for more information.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 05/07/2015 12:07 PM, Ulrich Hiller wrote:
login with the wrong password gives a denied login. login with the correct password always works.
This is my sitution since the begin of my thread.
Got it. I misread part of your last message, and thought that logins were /not/ working when sssd was running.
But instead i get centos: sshd[7929]: pam_unix(sshd:session): session opened for user
<username>
"pam_unix" should be an indication that <username> appears in the local unix password files. Make sure that it doesn't.
What do /etc/pam.d/sshd and /etc/pam.d/system-auth contain, currently?
So, maybe it is a pam problem.
Looks that way to me.
I have installed on centos: fprintd-pam-0.5.0-4.0.el7_0.x86_64 pam-1.1.8-12.el7.x86_64 gnome-keyring-pam-3.8.2-10.el7.x86_64 pam_krb5-2.4.8-4.el7.x86_64
Are you sure i do not need nss-pam-ldapd?
Yes. nss-pam-ldapd does, essentially, the same thing that sssd does. You also don't need pam_krb5. sssd has krb5 modules to support Kerberos login.
Googling around i have read something about a /etc/nslcd.conf which comes with this package. Is that needed?
No. Before sssd, there was nss_ldap. It sometimes caused boot problems by trying to connect to an LDAP server for user data before the network was up.
nss-pam-ldapd was written to address that with a daemon that handled queries, which was started after network init. That mostly solved the problem for LDAP.
sssd does mostly the same thing, but handles LDAP, krb5, as well as extensions for FreeIPA and Active Directory. It can cache credentials for offline use (for laptops). When using sssd, you don't need the older PAM or NSS modules.
On my opensuse i have much more:
I'm not terribly familiar with opensuse's authentication setup. Your log says you're using sss there, so most of those modules are probably installed but unused.
But instead i get centos: sshd[7929]: pam_unix(sshd:session): session opened for user
<username>
"pam_unix" should be an indication that <username> appears in the local unix password files. Make sure that it doesn't.
Nope. None of the usernames i tried is in /etc/passwd or /etc/shadow
What do /etc/pam.d/sshd and /etc/pam.d/system-auth contain, currently?
/etc/pam.d/sshd: ---------------- #%PAM-1.0 auth required pam_sepermit.so auth substack password-auth auth include postlogin account required pam_nologin.so account include password-auth password include password-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session optional pam_keyinit.so force revoke session include password-auth session include postlogin session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
/etc/pam.d/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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so auth required pam_env.so auth optional pam_gnome_keyring.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so account requisite pam_unix.so try_first_pass account sufficient pam_localuser.so account required pam_sss.so use_first_pass account sufficient pam_localuser.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so password requisite pam_cracklib.so password optional pam_gnome_keyring.so use_authtok password sufficient pam_unix.so use_authtok nullok shadow try_first_pass password required pam_sss.so use_authtok
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session sufficient pam_sss.so session required pam_unix.so try_first_pass session optional pam_umask.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm
With kind regards, ulrich
On 05/08/2015 08:14 AM, Ulrich Hiller wrote:
With kind regards, ulrich
Hm. I don't *see* the problem, so let me go about this in the opposite direction. I added the host controls to one of my systems, and they appear to work properly.
My configuration files were *mostly* written by "authconfig". It looks like you've done some manual tweaking with YaST examples. Some of the PAM stuff looks like it was tacked-on at the end of a sequence without understanding how PAM flow control works.
(Minor aside: you may have used authconfig --enablemd5, which weakens security somewhat. I believe the default is equivalent to authconfig --passalgo=sha256)
Your sssh pam file referenced password-auth (/etc/pam.d/password-auth) which should be a separate file from system-auth, but should have identical content.
I recommend starting with a completely clean system, setting up authentication with authconfig, and then modifying sssd.conf one setting at a time as you work toward your desired configuration.
/etc/sss/sssd.conf:
------
[domain/default]
autofs_provider = ldap cache_credentials = True krb5_realm = PRIVATE.EXAMPLE.NET ldap_search_base = dc=private,dc=example,dc=net krb5_server = directory.private.example.net:88 id_provider = ldap auth_provider = krb5 chpass_provider = krb5 ldap_uri = ldap://directory.private.example.net/ ldap_tls_cacertdir = /etc/openldap/cacerts krb5_store_password_if_offline = True krb5_kpasswd = directory.private.example.net:749
access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host
[sssd] services = nss, pam, autofs config_file_version = 2
domains = default [nss]
[pam]
[sudo]
[autofs]
[ssh]
[pac]
------
/etc/pam.d/system-auth-ac
------
#%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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass 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_sss.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 sha256 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
------
On May 8, 2015, at 11:14 AM, Ulrich Hiller hiller@mpia-hd.mpg.de wrote:
/etc/pam.d/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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so auth required pam_env.so auth optional pam_gnome_keyring.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so account requisite pam_unix.so try_first_pass account sufficient pam_localuser.so account required pam_sss.so use_first_pass account sufficient pam_localuser.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so password requisite pam_cracklib.so password optional pam_gnome_keyring.so use_authtok password sufficient pam_unix.so use_authtok nullok shadow try_first_pass password required pam_sss.so use_authtok
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session sufficient pam_sss.so session required pam_unix.so try_first_pass session optional pam_umask.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm
Is it normal to have pam_unix and pam_sss twice for each each section?
-- Jonathan Billings billings@negate.org
Hmmm...., i have made now a complete new install but the problem persists: ldap authentication works, but the host attribute is ignored.
I have installed CentOS7 64bit with KDE. I did not do any 'yum update' or install of extra packages so far.
these pam and ldap packages are installed: openldap-devel-2.4.39-6.el7.x86_64 openssh-ldap-6.6.1p1-11.el7.x86_64 openldap-2.4.39-6.el7.x86_64 python-ldap-2.4.15-2.el7.x86_64 compat-openldap-2.3.43-5.el7.x86_64 openldap-clients-2.4.39-6.el7.x86_64 fprintd-pam-0.5.0-4.0.el7_0.x86_64 gnome-keyring-pam-3.8.2-10.el7.x86_64 pam-1.1.8-12.el7.x86_64
I ran authconfig-tui and set "use ldap", "use md5 password", "use shadow password", "use ldap authentication", "use tls", "server=ldap://myldapserver.com", "basedn=o=XXX"
my /etc/openldap/ldap.conf: BASE o=XXX URI ldap://myldapserver.com/ TLS_CACERTDIR /etc/ssl/certs SASL_NOCANON on
My /etc/sssd/sssd.conf: [domain/default] ldap_uri = ldap://myldapserver.com/ ldap_search_base = ou=YYY,o=XXX ldap_schema = rfc2307bis id_provider = ldap ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid ldap_id_use_start_tls = True enumerate = False cache_credentials = False ldap_tls_cacertdir = /etc/openldap/cacerts/ chpass_provider = ldap auth_provider = ldap ldap_tls_reqcert = never ldap_user_search_base = ou=YYY,o=XXX access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host autofs_provider = ldap
[sssd] services = nss, pam, autofs config_file_version = 2 domains = default
[nss]
[pam]
[sudo]
[autofs]
[ssh]
My /etc/pam.d/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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.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 md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
My /etc/pam.d/password-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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.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 md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
My /etc/nsswitch.conf: passwd: files sss shadow: files sss group: files sss hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files sss aliases: files nisplus
nscd is NOT installed
apart from the uid boundary interval in /etc/pam-d i left the files in this directory as they were created by authconfig. I did not copy anything from other systems.
ldapsearch can read the user information. The user can again login, no matter of the contence of the ldap's host attribute.
I feel a bit embarrassed now. but ... does anybody have another idea?
With kind regards, ulrich
one more thing: firewalld service and selinux are deactivated.
On 05/11/2015 07:06 PM, Ulrich Hiller wrote:
Hmmm...., i have made now a complete new install but the problem persists: ldap authentication works, but the host attribute is ignored.
I have installed CentOS7 64bit with KDE. I did not do any 'yum update' or install of extra packages so far.
these pam and ldap packages are installed: openldap-devel-2.4.39-6.el7.x86_64 openssh-ldap-6.6.1p1-11.el7.x86_64 openldap-2.4.39-6.el7.x86_64 python-ldap-2.4.15-2.el7.x86_64 compat-openldap-2.3.43-5.el7.x86_64 openldap-clients-2.4.39-6.el7.x86_64 fprintd-pam-0.5.0-4.0.el7_0.x86_64 gnome-keyring-pam-3.8.2-10.el7.x86_64 pam-1.1.8-12.el7.x86_64
I ran authconfig-tui and set "use ldap", "use md5 password", "use shadow password", "use ldap authentication", "use tls", "server=ldap://myldapserver.com", "basedn=o=XXX"
my /etc/openldap/ldap.conf: BASE o=XXX URI ldap://myldapserver.com/ TLS_CACERTDIR /etc/ssl/certs SASL_NOCANON on
My /etc/sssd/sssd.conf: [domain/default] ldap_uri = ldap://myldapserver.com/ ldap_search_base = ou=YYY,o=XXX ldap_schema = rfc2307bis id_provider = ldap ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid ldap_id_use_start_tls = True enumerate = False cache_credentials = False ldap_tls_cacertdir = /etc/openldap/cacerts/ chpass_provider = ldap auth_provider = ldap ldap_tls_reqcert = never ldap_user_search_base = ou=YYY,o=XXX access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host autofs_provider = ldap
[sssd] services = nss, pam, autofs config_file_version = 2 domains = default
[nss]
[pam]
[sudo]
[autofs]
[ssh]
My /etc/pam.d/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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.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 md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
My /etc/pam.d/password-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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.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 md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
My /etc/nsswitch.conf: passwd: files sss shadow: files sss group: files sss hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files sss aliases: files nisplus
nscd is NOT installed
apart from the uid boundary interval in /etc/pam-d i left the files in this directory as they were created by authconfig. I did not copy anything from other systems.
ldapsearch can read the user information. The user can again login, no matter of the contence of the ldap's host attribute.
I feel a bit embarrassed now. but ... does anybody have another idea?
With kind regards, ulrich
I am still not understanding why your using MD5? Is it because everyone in InfoSec declared that everyone finally went from md5 to sha512 or what?
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Ulrich Hiller Sent: Monday, May 11, 2015 1:40 PM To: CentOS mailing list Subject: Re: [CentOS] ldap host attribute is ignored
one more thing: firewalld service and selinux are deactivated.
On 05/11/2015 07:06 PM, Ulrich Hiller wrote:
Hmmm...., i have made now a complete new install but the problem persists: ldap authentication works, but the host attribute is ignored.
I have installed CentOS7 64bit with KDE. I did not do any 'yum update' or install of extra packages so far.
these pam and ldap packages are installed: openldap-devel-2.4.39-6.el7.x86_64 openssh-ldap-6.6.1p1-11.el7.x86_64 openldap-2.4.39-6.el7.x86_64 python-ldap-2.4.15-2.el7.x86_64 compat-openldap-2.3.43-5.el7.x86_64 openldap-clients-2.4.39-6.el7.x86_64 fprintd-pam-0.5.0-4.0.el7_0.x86_64 gnome-keyring-pam-3.8.2-10.el7.x86_64 pam-1.1.8-12.el7.x86_64
I ran authconfig-tui and set "use ldap", "use md5 password", "use shadow password", "use ldap authentication", "use tls", "server=ldap://myldapserver.com", "basedn=o=XXX"
my /etc/openldap/ldap.conf: BASE o=XXX URI ldap://myldapserver.com/ TLS_CACERTDIR /etc/ssl/certs SASL_NOCANON on
My /etc/sssd/sssd.conf: [domain/default] ldap_uri = ldap://myldapserver.com/ ldap_search_base = ou=YYY,o=XXX ldap_schema = rfc2307bis id_provider = ldap ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid ldap_id_use_start_tls = True enumerate = False cache_credentials = False ldap_tls_cacertdir = /etc/openldap/cacerts/ chpass_provider = ldap auth_provider = ldap ldap_tls_reqcert = never ldap_user_search_base = ou=YYY,o=XXX access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host autofs_provider = ldap
[sssd] services = nss, pam, autofs config_file_version = 2 domains = default
[nss]
[pam]
[sudo]
[autofs]
[ssh]
My /etc/pam.d/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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.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 md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
My /etc/pam.d/password-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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.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 md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
My /etc/nsswitch.conf: passwd: files sss shadow: files sss group: files sss hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files sss aliases: files nisplus
nscd is NOT installed
apart from the uid boundary interval in /etc/pam-d i left the files in this directory as they were created by authconfig. I did not copy anything from other systems.
ldapsearch can read the user information. The user can again login, no matter of the contence of the ldap's host attribute.
I feel a bit embarrassed now. but ... does anybody have another idea?
With kind regards, ulrich
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ok, i deactivated md5 in authconfig. And the problem persists. But i do not see the relation to my problem. The authentication works like charm. It is only the ldap's host attribute which is ignored.
With kind regards, ulrich
On 05/11/2015 07:48 PM, Conley, Matthew M CTR GXM wrote:
I am still not understanding why your using MD5? Is it because everyone in InfoSec declared that everyone finally went from md5 to sha512 or what?
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Ulrich Hiller Sent: Monday, May 11, 2015 1:40 PM To: CentOS mailing list Subject: Re: [CentOS] ldap host attribute is ignored
one more thing: firewalld service and selinux are deactivated.
On 05/11/2015 07:06 PM, Ulrich Hiller wrote:
Hmmm...., i have made now a complete new install but the problem persists: ldap authentication works, but the host attribute is ignored.
I have installed CentOS7 64bit with KDE. I did not do any 'yum update' or install of extra packages so far.
these pam and ldap packages are installed: openldap-devel-2.4.39-6.el7.x86_64 openssh-ldap-6.6.1p1-11.el7.x86_64 openldap-2.4.39-6.el7.x86_64 python-ldap-2.4.15-2.el7.x86_64 compat-openldap-2.3.43-5.el7.x86_64 openldap-clients-2.4.39-6.el7.x86_64 fprintd-pam-0.5.0-4.0.el7_0.x86_64 gnome-keyring-pam-3.8.2-10.el7.x86_64 pam-1.1.8-12.el7.x86_64
I ran authconfig-tui and set "use ldap", "use md5 password", "use shadow password", "use ldap authentication", "use tls", "server=ldap://myldapserver.com", "basedn=o=XXX"
my /etc/openldap/ldap.conf: BASE o=XXX URI ldap://myldapserver.com/ TLS_CACERTDIR /etc/ssl/certs SASL_NOCANON on
My /etc/sssd/sssd.conf: [domain/default] ldap_uri = ldap://myldapserver.com/ ldap_search_base = ou=YYY,o=XXX ldap_schema = rfc2307bis id_provider = ldap ldap_user_uuid = entryuuid ldap_group_uuid = entryuuid ldap_id_use_start_tls = True enumerate = False cache_credentials = False ldap_tls_cacertdir = /etc/openldap/cacerts/ chpass_provider = ldap auth_provider = ldap ldap_tls_reqcert = never ldap_user_search_base = ou=YYY,o=XXX access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host autofs_provider = ldap
[sssd] services = nss, pam, autofs config_file_version = 2 domains = default
[nss]
[pam]
[sudo]
[autofs]
[ssh]
My /etc/pam.d/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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.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 md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
My /etc/pam.d/password-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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.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 md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
My /etc/nsswitch.conf: passwd: files sss shadow: files sss group: files sss hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files sss aliases: files nisplus
nscd is NOT installed
apart from the uid boundary interval in /etc/pam-d i left the files in this directory as they were created by authconfig. I did not copy anything from other systems.
ldapsearch can read the user information. The user can again login, no matter of the contence of the ldap's host attribute.
I feel a bit embarrassed now. but ... does anybody have another idea?
With kind regards, ulrich
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 05/11/2015 10:06 AM, Ulrich Hiller wrote:
Hmmm...., i have made now a complete new install but the problem persists: ldap authentication works, but the host attribute is ignored.
Hate to say that we're running out of options. I had a CentOS 7 system similar to yours, with LDAP authentication. I added three lines to sssd.conf (for access provider, etc), restarted sssd, and users with no "host" attribute were denied. I didn't actually test users with a host attribute that didn't match, or with deny rules. So maybe there's a bug that needs to be looked at? Does authentication work for users that have no "host" attribute at all?
I have installed CentOS7 64bit with KDE. I did not do any 'yum update' or install of extra packages so far.
Update, see if that makes a difference.
After that you'll probably have to turn up logging in sssd and check its logs to see what it's doing.
Hate to say that we're running out of options. I had a CentOS 7 system similar to yours, with LDAP authentication. I added three lines to sssd.conf (for access provider, etc), restarted sssd, and users with no "host" attribute were denied. I didn't actually test users with a host attribute that didn't match, or with deny rules. So maybe there's a bug that needs to be looked at? Does authentication work for users that have no "host" attribute at all?
yes, it works for users that have no "host" attribute at all
I have installed CentOS7 64bit with KDE. I did not do any 'yum update' or install of extra packages so far.
Update, see if that makes a difference.
i did it, rebooted it. No differnce
After that you'll probably have to turn up logging in sssd and check its logs to see what it's doing.
That's a good hint. I'll do that tomorrow.
With kind regards, ulrich
After that you'll probably have to turn up logging in sssd and check its logs to see what it's doing.
i have set logging in sssd to 9: cache_credentials = true debug_level = 9
I first tried a user with the correct host attribute, then a user without the host attribute. The output in the logfiles are the same.
Note: USER ist not a local user. Without correct ldap password the user cannot login.
User with correct host attribute -------------------------------- (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): command: PAM_SETCRED (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): domain: default (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): user: USER (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): service: sshd (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): tty: ssh (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): ruser: (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): rhost: myhost.mydomain.com (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): authtok type: 0 (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): priv: 0 (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): cli_pid: 5921 (Tue May 12 13:16:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): logon name: not set
journalctl: May 12 13:16:36 localhost sshd[5917]: pam_unix(sshd:auth): unrecognized ENCRYPT_METHOD value [DES] May 12 13:16:36 localhost sshd[5917]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=myhost.mydomain.com user=USER May 12 13:16:36 localhost sshd[5917]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=myhost.mydomain.com user=USER May 12 13:16:36 localhost sshd[5917]: pam_unix(sshd:account): unrecognized ENCRYPT_METHOD value [DES] May 12 13:16:36 localhost sshd[5917]: Accepted password for USER from 999.999.999.999 port 33399 ssh2 May 12 13:16:36 localhost systemd[1]: Starting user-501.slice. May 12 13:16:36 localhost systemd[1]: Created slice user-501.slice. May 12 13:16:36 localhost systemd[1]: Starting Session 24 of user USER. May 12 13:16:36 localhost systemd[1]: Started Session 24 of user USER. May 12 13:16:36 localhost systemd-logind[601]: New session 24 of user USER. May 12 13:16:36 localhost sshd[5917]: pam_unix(sshd:session): unrecognized ENCRYPT_METHOD value [DES] May 12 13:16:36 localhost sshd[5917]: pam_unix(sshd:session): session opened for user USER by (uid=0) May 12 13:16:40 localhost sshd[5921]: Received disconnect from 999.999.999.999: 11: disconnected by user May 12 13:16:40 localhost sshd[5917]: pam_unix(sshd:session): unrecognized ENCRYPT_METHOD value [DES] May 12 13:16:40 localhost sshd[5917]: pam_unix(sshd:session): session closed for user USER May 12 13:16:40 localhost systemd-logind[601]: Removed session 24.
User without host attribute: ---------------------------- sssd.log:
(Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): command: PAM_CLOSE_SESSION (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): domain: default (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): user: USER (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): service: sshd (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): tty: ssh (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): ruser: (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): rhost: myhost.mydomain.com (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): authtok type: 0 (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): priv: 1 (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): cli_pid: 6051 (Tue May 12 13:27:46 2015) [sssd[be[default]]] [pam_print_data] (0x0100): logon name: not set
journalctl: May 12 13:27:44 localhost sshd[6051]: pam_unix(sshd:auth): unrecognized ENCRYPT_METHOD value [DES] May 12 13:27:44 localhost sshd[6051]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=myhost.mydomain.com user=USER May 12 13:27:44 localhost sshd[6051]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=myhost.mydomain.com user=USER May 12 13:27:44 localhost sshd[6051]: pam_unix(sshd:account): unrecognized ENCRYPT_METHOD value [DES] May 12 13:27:44 localhost sshd[6051]: Accepted password for USER from 999.999.999.999 port 33417 ssh2 May 12 13:27:44 localhost systemd[1]: Created slice user-501.slice. May 12 13:27:44 localhost systemd[1]: Starting Session 26 of user USER. May 12 13:27:44 localhost systemd[1]: Started Session 26 of user USER. May 12 13:27:44 localhost systemd-logind[601]: New session 26 of user USER. May 12 13:27:44 localhost sshd[6051]: pam_unix(sshd:session): unrecognized ENCRYPT_METHOD value [DES] May 12 13:27:44 localhost sshd[6051]: pam_unix(sshd:session): session opened for user USER by (uid=0) May 12 13:27:46 localhost sshd[6053]: Received disconnect from 999.999.999.999: 11: disconnected by user May 12 13:27:46 localhost sshd[6051]: pam_unix(sshd:session): unrecognized ENCRYPT_METHOD value [DES] May 12 13:27:46 localhost sshd[6051]: pam_unix(sshd:session): session closed for user USER May 12 13:27:46 localhost systemd-logind[601]: Removed session 26.
Does this give anyone a clue? Whereelse can i look into?
With kind regards, ulrich
On 05/12/2015 06:25 AM, Ulrich Hiller wrote:
i have set logging in sssd to 9:
7 might be good enough for what you want to find. I added this to domain/default section:
access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host debug_level = 7
/var/log/sssd/sssd_default.log logged the following for one user which had no "host" attribute, and was denied login:
----- (Tue May 12 10:35:35 2015) [sssd[be[default]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [dc=private,dc=example,dc=net] (Tue May 12 10:35:35 2015) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=gordon)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))][dc=private,dc=example,dc=net]. (Tue May 12 10:35:35 2015) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] ... (Tue May 12 10:35:35 2015) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] -----
So, the user lookup definitely requested the host attribute.
The authentication process logs to the same file:
----- (Tue May 12 10:35:36 2015) [sssd[be[default]]] [be_pam_handler] (0x0100): Got request with the following data (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): domain: default (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): user: gordon (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): service: sshd (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): tty: ssh (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): ruser: (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): rhost: 10.1.10.41 (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): authtok type: 0 (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): priv: 1 (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): cli_pid: 7871 (Tue May 12 10:35:36 2015) [sssd[be[default]]] [sdap_access_send] (0x0400): Performing access check for user [gordon] (Tue May 12 10:35:36 2015) [sssd[be[default]]] [sdap_access_host] (0x0020): Missing hosts. Access denied -----
Your log excerpt did not include "performing access check". I don't know if that's because it isn't in your log or because your excerpt was too short.
that's intersting. "performing access check" is really missing.
also the "sdap_access" lines are not there. Therefore i do have:
(Tue May 12 13:16:20 2015) [sssd[be[default]]] [dp_get_options] (0x0400): Option ldap_access_filter has no value (Tue May 12 13:16:20 2015) [sssd[be[default]]] [dp_get_options] (0x0400): Option ldap_access_order has value host (Tue May 12 13:16:20 2015) [sssd[be[default]]] [be_process_init] (0x2000): ACCESS backend target successfully loaded from provider [ldap].
"Requesting attrs: [objectClass]" and "Requesting attrs: [host]" are in the logfile.
So there is no access check apart from username and password check - otherwise i would not have been able to login.
The question is why doesn't it perform these checks.
Just to repete: My sssd.conf contains access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host
I read something about "pam_check_host_attr" in /etc/ldap.conf But this does not help in my /etc/openldap/ldap.conf (already tested).
Any idea is still welcome.
With kind regards, ulrich
On 05/12/2015 07:45 PM, Gordon Messmer wrote:
On 05/12/2015 06:25 AM, Ulrich Hiller wrote:
i have set logging in sssd to 9:
7 might be good enough for what you want to find. I added this to domain/default section:
access_provider = ldap ldap_access_order = host ldap_user_authorized_host = host debug_level = 7
/var/log/sssd/sssd_default.log logged the following for one user which had no "host" attribute, and was denied login:
(Tue May 12 10:35:35 2015) [sssd[be[default]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [dc=private,dc=example,dc=net] (Tue May 12 10:35:35 2015) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=gordon)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))][dc=private,dc=example,dc=net].
(Tue May 12 10:35:35 2015) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] ... (Tue May 12 10:35:35 2015) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host]
So, the user lookup definitely requested the host attribute.
The authentication process logs to the same file:
(Tue May 12 10:35:36 2015) [sssd[be[default]]] [be_pam_handler] (0x0100): Got request with the following data (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): domain: default (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): user: gordon (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): service: sshd (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): tty: ssh (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): ruser: (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): rhost: 10.1.10.41 (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): authtok type: 0 (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): priv: 1 (Tue May 12 10:35:36 2015) [sssd[be[default]]] [pam_print_data] (0x0100): cli_pid: 7871 (Tue May 12 10:35:36 2015) [sssd[be[default]]] [sdap_access_send] (0x0400): Performing access check for user [gordon] (Tue May 12 10:35:36 2015) [sssd[be[default]]] [sdap_access_host] (0x0020): Missing hosts. Access denied
Your log excerpt did not include "performing access check". I don't know if that's because it isn't in your log or because your excerpt was too short. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ulrich Hiller wrote:
that's intersting. "performing access check" is really missing.
also the "sdap_access" lines are not there. Therefore i do have:
(Tue May 12 13:16:20 2015) [sssd[be[default]]] [dp_get_options] (0x0400): Option ldap_access_filter has no value (Tue May 12 13:16:20 2015) [sssd[be[default]]] [dp_get_options] (0x0400): Option ldap_access_order has value host (Tue May 12 13:16:20 2015) [sssd[be[default]]] [be_process_init] (0x2000): ACCESS backend target successfully loaded from provider [ldap].
<snip> I really don't know this level, but from the above, my first reaction is to see if there has to be an ldab_access_filter that then leads to the ldap_access_order in the chain.
mark
i thought this too. I think this:
access_provider = ldap ldap_access_filter = memberOf=host=does-not-exist-host ldap_access_order = filter ldap_user_authorized_host = host
must confuse sssd so much that it denies login. But the user without host attribute can still login.
With kind regards, ulrich
On 05/12/2015 09:23 PM, m.roth@5-cent.us wrote:
Ulrich Hiller wrote:
that's intersting. "performing access check" is really missing.
also the "sdap_access" lines are not there. Therefore i do have:
(Tue May 12 13:16:20 2015) [sssd[be[default]]] [dp_get_options] (0x0400): Option ldap_access_filter has no value (Tue May 12 13:16:20 2015) [sssd[be[default]]] [dp_get_options] (0x0400): Option ldap_access_order has value host (Tue May 12 13:16:20 2015) [sssd[be[default]]] [be_process_init] (0x2000): ACCESS backend target successfully loaded from provider [ldap].
<snip> I really don't know this level, but from the above, my first reaction is to see if there has to be an ldab_access_filter that then leads to the ldap_access_order in the chain.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ulrich Hiller wrote:
i thought this too. I think this:
access_provider = ldap ldap_access_filter = memberOf=host=does-not-exist-host ldap_access_order = filter ldap_user_authorized_host = host
must confuse sssd so much that it denies login. But the user without host attribute can still login.
Wait - are you saying that it didn't deny, but now it does? If that's the case, then you're almost there, just that the condition is backwards (like sshd_config, with PermitRootLogin Without-Password means that you have to use a key, not that it permits root to come in without a password....
mark
On 05/12/2015 11:04 PM, m.roth@5-cent.us wrote:
Ulrich Hiller wrote:
i thought this too. I think this:
access_provider = ldap ldap_access_filter = memberOf=host=does-not-exist-host ldap_access_order = filter ldap_user_authorized_host = host
must confuse sssd so much that it denies login. But the user without host attribute can still login.
Wait - are you saying that it didn't deny, but now it does? If that's the case, then you're almost there, just that the condition is backwards (like sshd_config, with PermitRootLogin Without-Password means that you have to use a key, not that it permits root to come in without a password....
mark
No. Sorry for the misunderstanding (i am not a native English speaker). I wanted to say that it still does *not* deny.
yessterday we ha a public holiday here. Now i am bach. ;-)
the uid is below 2000. If you want to know the real number: it is 1026. But when i set the 2000 to 1000: account sufficient pam_succeed_if.so uid < 1000 quiet i cannot login at all. "Permission denied"
With kind regards, ulrich
On 05/13/2015 06:36 PM, Gordon Messmer wrote:
On 05/12/2015 11:47 AM, Ulrich Hiller wrote:
that's intersting. "performing access check" is really missing.
OK.... Your system is configured to not check users with uidNumber < 2000. Your original message obscured the UID of the user you were testing. What is it?
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 05/15/2015 03:07 AM, Ulrich Hiller wrote:
the uid is below 2000. If you want to know the real number: it is 1026.
I'm happy to help, but I have to point out that we've been chasing this problem for ten days now, and the problem would be been pretty obvious if you had not obscured the uidNumber to begin with.
Please don't obscure information that isn't security-sensitive.
Your uidNumber is not sensitive. Your Samba SID is not sensitive. These things can't be used to launch an attack on your system. Obscuring them wastes your time, above all.
But when i set the 2000 to 1000: account sufficient pam_succeed_if.so uid < 1000 quiet i cannot login at all. "Permission denied"
What do the logs say? If the "secure" log doesn't clarify the problem, then set debugging on sssd to 7 and check that log as well.
It's not normal to have pam_unix.so twice in each group. That said, I am not used to seeing nullok in these as well. (The environment I work in requires it removed, so that's why it's strange to see.) pam_systemd.so and md5?
I wanted to clean this up a bit, but I am going to stop now, cause I see the reference of Centos 5 based info and CentOS 7 stuff. I will have to see what's changed between the both. Here's what I have thus far. #%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 sufficient pam_unix.so try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so auth optional pam_gnome_keyring.so
account required pam_unix.so broken_shadow try_first_pass account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so account sufficient pam_localuser.so account required pam_sss.so use_first_pass account sufficient pam_localuser.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so password requisite pam_cracklib.so password optional pam_gnome_keyring.so use_authtok password required pam_sss.so use_authtok
session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so try_first_pass session sufficient pam_sss.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jonathan Billings Sent: Saturday, May 09, 2015 4:25 PM To: CentOS mailing list Subject: Re: [CentOS] ldap host attribute is ignored
On May 8, 2015, at 11:14 AM, Ulrich Hiller hiller@mpia-hd.mpg.de wrote:
/etc/pam.d/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 sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 200 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so auth required pam_env.so auth optional pam_gnome_keyring.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 2000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so account requisite pam_unix.so try_first_pass account sufficient pam_localuser.so account required pam_sss.so use_first_pass account sufficient pam_localuser.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so password requisite pam_cracklib.so password optional pam_gnome_keyring.so use_authtok password sufficient pam_unix.so use_authtok nullok shadow try_first_pass password required pam_sss.so use_authtok
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session sufficient pam_sss.so session required pam_unix.so try_first_pass session optional pam_umask.so session optional pam_gnome_keyring.so auto_start only_if=gdm,gdm-password,lxdm,lightdm
-- Jonathan Billings billings@negate.org
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Ashish Yadav -
Conley, Matthew M CTR GXM -
Gordon Messmer -
Jonathan Billings -
Kai Grunau -
m.roth＠5-cent.us -
Ulrich Hiller