Ldap Host Attribute Is Ignored
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:
—————————————-
36 thoughts on - Ldap Host Attribute Is Ignored
Hi,
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
hi,
try instead of “ldap_access_order = host” parameter
“ldap_access_filter = host=’HOSTNAME’ ” to use
regards, Kai
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.
Ulrich Hiller wrote:
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
/etc/openLDAP/ldap.conf is the configuration file for openLDAP clients.
It is not used for system authentication or name service.
Those two files have completely different syntax and are used by different software. Don’t symlink them.
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.
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.
nscd is also not used when using sssd.
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.
I already have seen this page, but it does not help me. But anyway, thanks a lot for your help.
With kind regards, ulrich
i deleted the link now. /etc/ldap.conf was not present before. I gave openLDAP
ldap_access_filter is now commented out.
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.
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:] sections, and
[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/
# 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
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.
That seems consistent with having “ldap” in nsswitch.conf and no
/etc/ldap.conf.
Don’t use “ldap”. Use “sss”.
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.
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
Looks good.
OK, but that file isn’t used for name service or authentication. Mostly just the openLDAP tools (ldapsearch, ldapadd, ldapmodify).
…
nitpick: those are the defaults. Probably don’t need to set them.
Not sure about that setting. “allow” is probably what you want if you’re using starttls.
…
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” or “getent passwd ” 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
and getent passwd and ldapsearch -x -b “ou=XXX,o=YYY” uid=
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
But instead i get CentOS: sshd[7929]: pam_unix(sshd:session): session opened for user
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?
Got it. I misread part of your last message, and thought that logins were /not/ working when sssd was running.
“pam_unix” should be an indication that 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?
Looks that way to me.
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.
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.
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.
Nope. None of the usernames i tried is in /etc/passwd or /etc/shadow
/etc/pam.d/sshd:
————–
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:
—-
Is it normal to have pam_unix and pam_sss twice for each each section?
No. See my previous message. I think it’s the result of copying portions of SuSE configurations.
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
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
one more thing: firewalld service and selinux are deactivated.
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—
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
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?
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.
yes, it works for users that have no “host” attribute at all
i did it, rebooted it. No differnce
That’s a good hint. I’ll do that tomorrow.
With kind regards, ulrich
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
——————————
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:
—
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
Ulrich Hiller wrote:
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
Ulrich Hiller wrote:
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.
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?
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
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.
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.