[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Autenticacion desde un linux hacia ldap

On Thursday 19 May 2011 02:27:21 pm Eduardo R. Barrera Pérez wrote:
> El usuario o la contraseña son incorrectos, las letras deben teclearse con
> la capitalización correcta.
> Alguna idea????

unelos siguiendo esta guia aunque esta en ingles...


Install & configure libpam-ccreds on Ubuntu 5.10, 7.04, 7.10, 8.04. 
Your username and password are your credentials. Cached credentials are very 
useful for laptops on which user authentication is done via LDAP server. You 
are still able to authenticate with the accustomed login credentials when the 
LDAP server is not reachable. 
I will give a brief explanation on PAM. Linux-PAM is a system of libraries 
that handles all authentication in Ubuntu by default. A PAM is a Pluggable 
Authentication Module that is handled by Linux-PAM. Each module represents a 
particular authentication mechanism, and is named pam_xxxxx.so. pam_unix.so 
handles basic linux authentication using the /etc/passwd, /etc/group 
and /etc/shadow files. pam_ldap handles authentication using an LDAP 
database. And so on. 
Install the necessary packages. 
sudo apt-get install nss-updatedb libnss-db libpam-ccreds
Caches name service directories (passwd and group) locally. When a connection 
to the ldap server is available, create passwd.db and group.db. 
sudo nss_updatedb ldap
  passwd... done.
  group... done.
ls -l /var/lib/misc/*.db
  -rw-r--r-- 1 root root 8192 2008-08-26 18:20 /var/lib/misc/group.db
  -rw-r--r-- 1 root root 8192 2008-08-26 18:20 /var/lib/misc/passwd.db
Use anacron to run this no earlier than 5 minutes after boot-up, once a day 
echo '#!/bin/sh'               | sudo tee    /etc/cron.daily/upd-local-nss-db
echo `which nss_updatedb` ldap | sudo tee -a /etc/cron.daily/upd-local-nss-db
sudo chmod +x /etc/cron.daily/upd-local-nss-db
NSS module for using Berkeley Databases as a naming service. This is needed to 
enable NSS to read the cached name service directories (passwd and group). 
Edit /etc/nsswitch.conf: 
passwd:         files ldap [NOTFOUND=return] db
group:          files ldap [NOTFOUND=return] db
This means: 
look first in the local files (/etc/passwd and /etc/group) 
if not found, use LDAP 
when LDAP does not have user information, exit and return nothing (this is the 
[NOTFOUND=return] directive) 
if the LDAP server was not reachable, proceed with using the cached data 
You can test if passwd and group are cached properly by disconnecting the 
network connection and listing the users: 
ifdown eth0
sudo getent passwd
This should return the local user plus the users from the ldap server cache in 
the passwd.db. 
Pam module to cache authentication credentials (i.e. passwords) locally 
in /var/cache/.security.db. 
You need to edit /etc/pam.d/common-auth as follows: 
auth    [success=done default=ignore]   pam_unix.so nullok_secure 
# If LDAP is unavailable, go to next line.  If authentication via LDAP is 
successful, skip 1 line.
# If LDAP is available, but authentication is NOT successful, skip 2 lines.
auth    [authinfo_unavail=ignore success=1 default=2] pam_ldap.so 
auth    [default=done]  pam_ccreds.so action=validate use_first_pass
auth    [default=done]  pam_ccreds.so action=store
auth    [default=bad]   pam_ccreds.so action=update
For Feisty only, if you get an error after "You have been logged on using 
cached credentials" saying "Authentication service cannot retrieve 
authentication info" you might need to make some more changes to your 
common-account file. Add the following line to /etc/pam.d/common-account: 
account required        pam_permit.so
If you are using Gutsy or Hardy you should have these lines 
in /etc/pam.d/common-account. 
account     [user_unknown=ignore authinfo_unavail=ignore default=done] 
account     [user_unknown=ignore authinfo_unavail=ignore default=done] 
account     required       pam_permit.so
After the file is adjusted properly you must login while connected to the LDAP 
server once to make libpam-ccreds store your password. After that you will be 
able to login while not connected to the ldap server as usual. 
In a fresh install of Hardy, pam_foreground.so does not exist. Comment out the 
pam_foreground line in /etc/pam.d/common-session. This removes this error 
from /var/log/auth.log - 'PAM [error: /lib/security/pam_foreground.so: cannot 
open shared object file: No such file or directory]'. Until you fix this, you 
may not be able to use GUI programs that are used to change system settings - 
eg. the network manager. 
session    required     pam_unix.so
session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077
session    optional     pam_ldap.so
#session    optional     pam_foreground.so
There is a problem with libnss-ldap where, even for system users listed 
in /etc/passwd, LDAP is contacted to find out if the user is in any LDAP 
groups. This can cause the system to come to a virtual stand-still if the 
LDAP server is unavailable. To get around this problem, there is a directive 
called nss_initgroups_ignoreusers. List all your local system accounts after 
this directive. The article 
suggests the following options in /etc/ldap.conf. 
  timelimit 15
  bind_timelimit 15
  bind_policy soft
  nss_initgroups_ignoreusers root,sys,... and all your other local system 
accounts in /etc/passwd ...
If you have chosen to list all users in the initial logon dialog, this might 
crash when the LDAP server is unavailable. If so, disable this by setting the 
following line in /etc/gdm/gdm.conf-custom in the [greeter] section. 
  :  :
  :  :
The easiest way to test is by using su. While the LDAP server is available do 
something like this and check that .security.db has been updated. 
ls -l /var/cache/.security.db 
  -rw------- 1 root root 8192 2008-08-28 08:31 /var/cache/.security.db
  Thu Aug 28 10:09:03 EST 2008
su fred
ls -l /var/cache/.security.db 
  -rw------- 1 root root 8192 2008-08-28 10:09 /var/cache/.security.db
# the time stamp on .security.db shows that is has been updated with fred's 
You can run cc_dump. This is part of the libpam-ccreds package, and shows what 
passwords are stored in .security.db. 
sudo cc_dump 
  Credential Type  User             Service  Cached Credentials  
  Salted SHA1      fred             any     
This failed for me when the user account's password was not encrypted as 
{SSHA} in the LDAP database. Using smbldap-passwd to change the password 
fixed this problem. 
Now disconnect the PC from the network (or shutdown the LDAP service) and do 
similar to this. 
su fred
  You have been logged on using cached credentials.
# It works!
Warning for Ubuntu 5.01 Only
The packages needed for this feature are linked against libdb. To my 
experience all packages need to be linked against the same libdb to make 
everything work properly. This is not the case with ubuntu 5.10 were the 
installed packages would be the following: 
Instead of libnss-db (2.2-6.3) i installed libnss-db (2.2.3) from the current 
debian testing (etch). 
As mentioned above the libnss-db package from breezy/main is linked against 
libdb3 and will not work with nss-updatedb from breezy/universe. To 
circumvent this problem we need a package that is linked against libdb4.3 and 
auses no further dependencies. I recommend the libnss-db package from Debian 
testing (etch) which can be downloaded from 
http://packages.debian.org/testing/admin/libnss-db. To install the package 
open a terminal and type: 
sudo dpkg -i libnss-db_2.2.3pre1-1_i386
Further Information


 Administrador de redes
 Ministerio de Finanzas y Precios
 Linux user 366775
"En un problema con n ecuaciones
siempre habrá al menos n+1 incógnitas."

Reply to: