7:27 p.m.
On 05/02/2010, at 3:16 AM, Sean Carolan wrote:
> What is listed in your /etc/nsswitch.conf for passwd, shadow and
group?
Here's what I have on one of the clients:
passwd: files ldap
shadow: files ldap
group: files ldap
> If you do not have an entry for 'files' then the local
/etc/{passwd,shadow,group} files will not be searched.
Should it not try "files" first? I'm still seeing that when the LDAP
server is down, I can't log onto the client machines at all. Logging
in as root works, but logging in as a normal user doesn't. Any
suggestions?
Yes, it should...
This may be a silly question, but -- if you remove/disable the LDAP config, can you log in
with the local account?
9:41 p.m.
New subject: With LDAP server stopped, local authentication fails...
Tom Lanyon wrote:
On 05/02/2010, at 3:16 AM, Sean Carolan wrote:
>> What is listed in your /etc/nsswitch.conf for passwd, shadow and group?
>>
> Here's what I have on one of the clients:
>
> passwd: files ldap
> shadow: files ldap
> group: files ldap
>
>
>> If you do not have an entry for 'files' then the local
/etc/{passwd,shadow,group} files will not be searched.
>>
> Should it not try "files" first? I'm still seeing that when the LDAP
> server is down, I can't log onto the client machines at all. Logging
> in as root works, but logging in as a normal user doesn't. Any
> suggestions?
>
Yes, it should...
It probably does. The fun starts when it has to check every LDAP group
to see if that person is a member of one of them, and for that it *must*
go to LDAP, regardless of the order in nsswitch.conf.
You can disable that behavior on an account-by-account basis using the
nss_initgroups_ignoreusers in ldap.conf, and there may be other ways.
One alternative may just be to set the LDAP timeout short enough that
the login timeout doesn't kick in before the LDAP one does. There may
be others as well.
10:01 p.m.
New subject: With LDAP server stopped, local authentication fails...
On Thu, Feb 4, 2010 at 10:41 PM, Morris, Patrick <patrick.morris(a)hp.com> wrote:
Tom Lanyon wrote:
> On 05/02/2010, at 3:16 AM, Sean Carolan wrote:
>
>
>>> What is listed in your /etc/nsswitch.conf for passwd, shadow and group?
>>>
>> Here's what I have on one of the clients:
>>
>> passwd: files ldap
>> shadow: files ldap
>> group: files ldap
>>
>>
>>> If you do not have an entry for 'files' then the local
/etc/{passwd,shadow,group} files will not be searched.
>>>
>> Should it not try "files" first? I'm still seeing that when the
LDAP
>> server is down, I can't log onto the client machines at all. Logging
>> in as root works, but logging in as a normal user doesn't. Any
>> suggestions?
>>
>
> Yes, it should...
>
It probably does. The fun starts when it has to check every LDAP group
to see if that person is a member of one of them, and for that it *must*
go to LDAP, regardless of the order in nsswitch.conf.
You can disable that behavior on an account-by-account basis using the
nss_initgroups_ignoreusers in ldap.conf, and there may be other ways.
One alternative may just be to set the LDAP timeout short enough that
the login timeout doesn't kick in before the LDAP one does. There may
be others as well.
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
The problem is probably in pam. Lot s of internet docs have incorrect
info advice and say.
account required pam_nologin.so
account sufficient pam_ldap.so
When you do that you get the situation you have now. In some phases of
login sufficient becomes required.
Try this:
#%PAM-1.0
auth sufficient pam_ldap.so
auth include system-auth
account required pam_nologin.so
account [default=bad success=ok user_unknown=ignore
service_err=ignore system_err=ignore authinfo_unavail=ignore]
pam_ldap.so
account include system-auth
password include system-auth
session optional pam_keyinit.so force revoke
session include system-auth
session required pam_loginuid.so
session required pam_mkhomedir.so
You can also throw arguments to pam_ldap.so to do something similar.
10:20 a.m.
New subject: With LDAP server stopped, local authentication fails...
The problem is probably in pam. Lot s of internet docs have
incorrect
info advice and say.
account required pam_nologin.so
account sufficient pam_ldap.so
When you do that you get the situation you have now. In some phases of
login sufficient becomes required.
Try this:
Before I go changing system-auth by hand I would like to see if there
is some way to get it working with the authconfig tool. This makes it
easier for me to maintain consistency and configure multiple systems.
Here is what is in my system-auth file now, and this was generated
with the following command. Is the authconfig tool actually
generating a "bad" configuration file? If so should this be
considered a bug?
/usr/sbin/authconfig --enablemkhomedir --enableldap --enableldapauth
--enablecache --ldapserver=example.company.com
--ldapbasedn="dc=company,dc=com" --enableldaptls --kickstart --update
#%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 >= 500 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass
use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session optional pam_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so
7:51 a.m.
New subject: With LDAP server stopped, local authentication fails...
On 06/02/2010, at 2:50 AM, Sean Carolan wrote:
> The problem is probably in pam. Lot s of internet docs have
incorrect
> info advice and say.
> account required pam_nologin.so
> account sufficient pam_ldap.so
>
> When you do that you get the situation you have now. In some phases of
> login sufficient becomes required.
>
> Try this:
Before I go changing system-auth by hand I would like to see if there
is some way to get it working with the authconfig tool. This makes it
easier for me to maintain consistency and configure multiple systems.
Here is what is in my system-auth file now, and this was generated
with the following command. Is the authconfig tool actually
generating a "bad" configuration file? If so should this be
considered a bug?
#%PAM-1.0
<snip>
Sean, Your system-auth pam config looks correct to me, and as you said, authconfig
shouldn't be generating 'bad' configs unless it contains a bug.
Edward was suggesting a problem with the 'login' pam service, not system-auth, but
I don't agree with his solution - I can't see how adding an explicit include of
pam_ldap.so here for the account type is going to help, as by default this just defers to
system-auth anyway.
Edward, are you able to offer any more insight into how this can help?
Regards,
Tom
8 a.m.
New subject: With LDAP server stopped, local authentication fails...
Edward was suggesting a problem with the 'login' pam service,
not system-auth, but I don't agree with his solution - I can't see how adding an
explicit include of pam_ldap.so here for the account type is going to help, as by default
this just defers to system-auth anyway.
Edward, are you able to offer any more insight into how this can help?
Thanks, Tom. I can provide log files or other data to troubleshoot
this. It's rather perplexing, we aren't trying to do anything really
out of the ordinary. This is a rather straightforward stock
installation of CentOS5 on the client, and CentOS5 with 389-ds on the
server.
11 a.m.
New subject: With LDAP server stopped, local authentication fails...
Here's a little more info on our little conundrum:
Only normal users who have ssh keys configured can log on. Password
authentication does not work at all when the LDAP server is down.
sudo commands do not work at all, they simply hang. I can't even
CTRL-C to cancel the sudo command after running it.
The moment I start up the LDAP server again all these problems go
away, and we are able to log on either with LDAP credentials or as a
normal, local user.
The problem is obviously somewhere on the client side of things, but
where? Does anyone else out there use CentOS5 with LDAP for
authentication? I can't imagine that my situation is unique.
11:37 a.m.
New subject: With LDAP server stopped, local authentication fails...
The problem is obviously somewhere on the client side of things, but
where? Does anyone else out there use CentOS5 with LDAP for
authentication? I can't imagine that my situation is unique.
A bit more investigation reveals the following:
This command prevents local users from logging on:
/usr/sbin/authconfig --enablemkhomedir --enableldap --enableldapauth
--enablecache --ldapserver=company.example.com
--ldapbasedn="dc=company,dc=com" --enableldaptls --kickstart --update
But if --enableldap is changed to --disableldap, then the local users
can log on and run sudo commands fine. This of course is all while
the LDAP server is down.
11:56 a.m.
New subject: With LDAP server stopped, local authentication fails...
On Thu, Feb 11, 2010 at 12:37 PM, Sean Carolan <scarolan(a)gmail.com> wrote:
> The problem is obviously somewhere on the client side of things,
but
> where? Does anyone else out there use CentOS5 with LDAP for
> authentication? I can't imagine that my situation is unique.
A bit more investigation reveals the following:
This command prevents local users from logging on:
/usr/sbin/authconfig --enablemkhomedir --enableldap --enableldapauth
--enablecache --ldapserver=company.example.com
--ldapbasedn="dc=company,dc=com" --enableldaptls --kickstart --update
But if --enableldap is changed to --disableldap, then the local users
can log on and run sudo commands fine. This of course is all while
the LDAP server is down.
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
The problem I described:
Docs will reference things like this:
account required pam_unix.so
account sufficent /usr/local/lib/pam_ldap.so
This works as long as the ldap server is up. But at some phases of pam
account 'sufficient' becomes 'required'. Also the ordering is
important thus ,Meaning during that phase when pam goes throw the user
stack it really becomes required. Thus if ldap is down, it fails.
You can play with this all day
account required /usr/local/lib/pam_ldap.so
account required pam_unix.so
Now your doomed because local users can not log in. The only correct
way to have pam work when ldap is down is like this:
account required pam_unix.so
account required /usr/local/lib/pam_ldap.so
ignore_unknown_user ignore_authinfo_unavail
Or you can replace 'ignore_unknown_user ignore_authinfo_unavail'
[default=bad success=ok user_unknown=ignore]
More or less 'ignore_unknown_user ignore_authinfo_unavail' are
special flags to the pam ldap module that make it react in a special
way when the user is not found or the ldap server is down.
True you do not have to edit pam.d/ssh as i suggested before, you can
edit the stack in a different way.
Before I go changing system-auth by hand I would like to see if there
is some way to get it working with the authconfig tool.
Authconfig is a nice tool, but I think there are many intrictate
interactions here, authconfig may not do exactly what you need in all
cases: LDAP auth is the most simple complicated thing, when you get it
rights its very clean, but there lots of layers and little settings
that have profound effects on things.
12:05 p.m.
New subject: With LDAP server stopped, local authentication fails...
But if --enableldap is changed to --disableldap, then the local
users
can log on and run sudo commands fine. This of course is all while
the LDAP server is down.
I may have narrowed down the problem a bit. Inside /etc/nsswitch.conf
there is a line that looks like this:
group: files ldap
It's as if the local system is searching for some group data on the
ldap server, but is never able to reach it so it just sits there and
hangs. If I remove the 'ldap' part from the end, logins work fine
with no issues even when the ldap server is down.
So my questions are:
1. Why is this group line gumming up the entire authentication process?
2. Do I need "ldap" on the group line? If I take it out how will it
affect my running systems?
1 p.m.
New subject: With LDAP server stopped, local authentication fails...
Hi Sean!
On Thu, 11 Feb 2010, Sean Carolan wrote:
> But if --enableldap is changed to --disableldap, then the local
users
> can log on and run sudo commands fine. This of course is all while
> the LDAP server is down.
I may have narrowed down the problem a bit. Inside /etc/nsswitch.conf
there is a line that looks like this:
group: files ldap
It's as if the local system is searching for some group data on the
ldap server, but is never able to reach it so it just sits there and
hangs. If I remove the 'ldap' part from the end, logins work fine
with no issues even when the ldap server is down.
So my questions are:
1. Why is this group line gumming up the entire authentication process?
2. Do I need "ldap" on the group line? If I take it out how will it
affect my running systems?
Answer to the "Why?" question:
You may have groups in LDAP that you don't have locally. The server has
no way to know. Those groups may include the person who just tried to
log in. The only way to know if those groups exist is to look in LDAP
and run through those groups to see if the person logging in is a member
of any of them, so it *is* going to try if you've told it to check LDAP
for group info.
Your basic problem seems to be that that lookup is taking far too long
to time out when the LDAP server is down. There are a lot of reasons
this might happen, but with the setup we use here (which is very near
identical to yours) the connection failure happens really fast, and PAM
just moves on. That, of course, assumes the LDAP server is not running
at all and not listening on port 389, which may or may not fit the
definition of "down" as you're using it here.
I should also probably note that this has probably not been an issue for
me with the same setup partially because, here, LDAP's critical, and we
make sure it's never down by using redundant systems, and it's really
unlikely here that LDAP will ever be completely unavailable... and since
we store login information there, I'd fully expect logins to fail if
LDAP was totally unavailable... I'd actually *want* them to fail, since
that's the one authoritative source of authentication we use. In the
same way, if we used local files, I'd expect logins to fail if someone
deleted /etc/shadow.
By the way, you don't *need* the ldap in the group spec in
nsswitch.conf... unless, of course, you want to access group information
from LDAP, in which case you do.
1:07 p.m.
New subject: With LDAP server stopped, local authentication fails...
On Thu, Feb 11, 2010 at 2:00 PM, <patrick.morris(a)hp.com> wrote:
Hi Sean!
On Thu, 11 Feb 2010, Sean Carolan wrote:
> > But if --enableldap is changed to --disableldap, then the local users
> > can log on and run sudo commands fine. This of course is all while
> > the LDAP server is down.
>
> I may have narrowed down the problem a bit. Inside /etc/nsswitch.conf
> there is a line that looks like this:
>
> group: files ldap
>
> It's as if the local system is searching for some group data on the
> ldap server, but is never able to reach it so it just sits there and
> hangs. If I remove the 'ldap' part from the end, logins work fine
> with no issues even when the ldap server is down.
>
> So my questions are:
>
> 1. Why is this group line gumming up the entire authentication process?
> 2. Do I need "ldap" on the group line? If I take it out how will it
> affect my running systems?
Answer to the "Why?" question:
You may have groups in LDAP that you don't have locally. The server has
no way to know. Those groups may include the person who just tried to
log in. The only way to know if those groups exist is to look in LDAP
and run through those groups to see if the person logging in is a member
of any of them, so it *is* going to try if you've told it to check LDAP
for group info.
Your basic problem seems to be that that lookup is taking far too long
to time out when the LDAP server is down. There are a lot of reasons
this might happen, but with the setup we use here (which is very near
identical to yours) the connection failure happens really fast, and PAM
just moves on. That, of course, assumes the LDAP server is not running
at all and not listening on port 389, which may or may not fit the
definition of "down" as you're using it here.
I should also probably note that this has probably not been an issue for
me with the same setup partially because, here, LDAP's critical, and we
make sure it's never down by using redundant systems, and it's really
unlikely here that LDAP will ever be completely unavailable... and since
we store login information there, I'd fully expect logins to fail if
LDAP was totally unavailable... I'd actually *want* them to fail, since
that's the one authoritative source of authentication we use. In the
same way, if we used local files, I'd expect logins to fail if someone
deleted /etc/shadow.
By the way, you don't *need* the ldap in the group spec in
nsswitch.conf... unless, of course, you want to access group information
from LDAP, in which case you do.
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
The best you can do here is set 'bind policy soft' ldap conf. Also
enable your chkconfig nscd on. If you are going to do ldap auth make
sure you have an LDAP cluster/farm and a load balancer or some high
availability systems. Things go pretty bad when your LDAP server is
down.
1:11 p.m.
New subject: With LDAP server stopped, local authentication fails...
The best you can do here is set 'bind policy soft' ldap conf.
Also
enable your chkconfig nscd on. If you are going to do ldap auth make
sure you have an LDAP cluster/farm and a load balancer or some high
availability systems. Things go pretty bad when your LDAP server is
down.
Yes, we actually just tested this with it set to "soft" and it solved
the problem. We do plan to load balance to multiple servers when this
goes to production. I just wanted to make sure that local accounts
could still log in while we transition over, even if LDAP is down.
1:18 p.m.
New subject: With LDAP server stopped, local authentication fails...
On Thu, Feb 11, 2010 at 2:11 PM, Sean Carolan <scarolan(a)gmail.com> wrote:
> The best you can do here is set 'bind policy soft' ldap
conf. Also
> enable your chkconfig nscd on. If you are going to do ldap auth make
> sure you have an LDAP cluster/farm and a load balancer or some high
> availability systems. Things go pretty bad when your LDAP server is
> down.
Yes, we actually just tested this with it set to "soft" and it solved
the problem. We do plan to load balance to multiple servers when this
goes to production. I just wanted to make sure that local accounts
could still log in while we transition over, even if LDAP is down.
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
In this case you should be fine. The only thing that periodically
happens is people will setup a crontab with an ldap user. If that
crontab becomes vital to operation it could fail if the LDAP server
goes away. That can be an issue, files owned by that user that may
live in a system area can be an issue in some edge cases.
5181
days inactive
5187
days old
389-users@lists.fedoraproject.org
13 comments
4 participants
participants (4)
-
Edward Capriolo -
Morris, Patrick -
Sean Carolan -
Tom Lanyon