Re: [gentoo-server] Complete migration from Scientific Linux with new features (Samba+AD/Winbind)

[Brian Kroth <bpkroth@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 9375 bytes --]

Vinícius Ferrão <viniciusferrao@cc.if.ufrj.br> 2011-11-02 23:00:
>   Really thanks Brian. Things appears to be working now... but I've some
>   issues, can you help-me solving this?
>
>   First of all, I cannot really understand what is going on. Kerberos is
>   still needed, as I can see.
>
>   I've emerged: sys-auth/nss-ldapd and sys-auth/pam_krb5; why nss-ldapd and
>   not nss_ldap? Because I can't get it working. Through your links I've
>   found
>   this: [1]https://help.ubuntu.com/community/ADWin2k8KerberosLDAP?highlight=%28%28ActiveDirectoryHowto%29%29
>
>   I followed the instructions but skipped the key tab generation in Windows
>   CLI. But configured the /etc/krb5.conf like this:
<snip/>
Ignoring the kerberos stuff as we were trying to focus on ldap.

>   /etc/nss-ldapd.conf
>   uri [5]ldap://ad.if.ufrj.br
>   base dc=if,dc=ufrj,dc=br
>   scope sub
>   binddn cn=ldapquery,cn=Users,dc=if,dc=ufrj,dc=br
>   bindpw procur4NOel3d4p3
>   filter passwd
>   (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
>   map passwd uid sAMAccountName
>   map passwd uidnumber uidNumber
>   map passwd homedirectory unixHomeDirectory
>   map passwd loginshell loginShell
>   map passwd gecos displayName
>   filter shadow
>   (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
>   map shadow uid sAMAccountName
>   filter group (objectClass=group)
>   map group uniqueMember member
>   /etc/nsswitch.conf
>   # $Header:
>   /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1
>   2006/09/29 23:52:23 vapier Exp $
>   # ldap added for AD Integration
>   passwd:      compat ldap
>   shadow:      compat
>   group:       compat ldap
>   # passwd:    db files nis
>   # shadow:    db files nis
>   # group:     db files nis
>   hosts:       files dns
>   networks:    files dns
>   services:    db files
>   protocols:   db files
>   rpc:         db files
>   ethers:      db files
>   netmasks:    files
>   netgroup:    files
>   bootparams:  files
>   automount:   files
>   aliases:     files

Okay, this stuff looks pretty good so far.

Next emerge pam_ldap and see where it dumps its conf by default (I don't 
have a gentoo machine handy atm so you'll have to dig.  It may be the 
same as the libnss-ldap (or its variant libnss-ldapd) or it may have a 
separate one (eg: /etc/pam_ldap.conf on debian).  In any case you can 
also specify it in the pam.d confs ... (man pam_ldap search for conf).
The syntax will be almost exactly the same as what you have in the other 
file.  In fact in the past they used to be the same file but each 
library had its own special directives as well as some shared ones.

>   And finally the most messed one: /etc/pam.d/system-auth
>   auth ~ # cat /etc/pam.d/system-auth
>   auth            required        pam_env.so
>   auth            sufficient      pam_krb5.so try_first_pass
>   auth            required        pam_unix.so likeauth nullok
>   auth            optional        pam_permit.so
>
>   account                 required        pam_unix.so
>   account                 optional        pam_permit.so
>
>   password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2
>   ocredit=2 retry=3
>   password        required        pam_unix.so use_authtok nullok sha512
>   shadow
>   password        sufficient      pam_krb5.so use_authtok
>   password        optional        pam_permit.so
>
>   session                 required        pam_limits.so
>   session                 required        pam_env.so
>   session                 required        pam_unix.so
>   session                 optional        pam_permit.so
>   I really need help in pam.d; don't know what I'm doing. But I'll continue
>   mixing this.

So this file is basically telling the system which authentication 
modules to use.  Focus on the auth section for the moment.  Note that 
krb5 is listed as a sufficient mechanism and pam_unix is listed as a 
required one.  What you basically want to do is replace the krb5 module 
there with the ldap module.  Then krb5 isn't in play for your system pam 
auth.

So, in my case they look like this:

# Check local authentication first, so root can still login
# while LDAP is down.
auth [success=1 default=ignore] pam_unix.so
auth required pam_ldap.so use_first_pass
auth required pam_permit.so

If you need to point it at a different pam_ldap.conf file (I do in the 
pam.d/sudo conf to provide different sudo passwords than the normal 
password by binding to a different shadow object in a different part of 
the ldap tree for instance), then you can use something like:

auth required pam_ldap.so use_first_pass config=/etc/pam_ldap.conf.sudo

Also note the comment regarding auth while ldap is unavailable.  The 
following (and low timeout values) has also helped in libnss-ldap.conf:

# This option directs the nss_ldap implementation of initgroups(3)
# to return NSS_STATUS_NOTFOUND if called with a listed  users  as
# its argument.  This should allow root to login in case of server 
# failure.
nss_initgroups_ignoreusers root

Hope that helps,
Brian

>   PS: The only disadvantage is the difficult to set it up working.
>   On Nov 1, 2011, at 10:58 PM, Brian Kroth wrote:
>
>     Actually, you don't even need kerberos for the authentication portion of
>     it.  You can have pam test the user's provided password by binding
>     against ldap directly to do that step.  I find this easier because it
>     avoids all the complexities of maintaining kerberos service tickets on
>     linux hosts entirely.  You may still wish to do that for some services
>     (eg: for single sign on for apache websites from windows ad clients, but
>     they probably still need to support passwords from non-domain clients,
>     so it's never seemed like a big win to me).  Doing that then requires
>     that your linux clients have tickets to make use of them, which is
>     another hassle.  It works in Windows clients a little bit more
>     naturally.
>
>     Anyways, on how to do it ...
>
>     there used to be some nice gentoo wiki articles on it.  They're giving
>     me 500 errors at the moment, so ...
>
>     The ubuntu page here [1] gives a reasonably good explanation of it
>     except that it also includes kerberos integration.  Basically to avoid
>     that, skip those sections, and rather than specifying pam_krb5.so in
>     those files, specify pam_ldap.so [2].
>
>     The handful of gotchas as I recall them:
>
>     - you have to setup a proxy user in order to do the base queries for
>       libnss-ldap [3] to find your account's dn so that pam_ldap can attempt
>       to bind as it.
>
>     - ad wants all of its connections to be ssl.  That might also mean that
>       you have to setup the cert for it (usually obtainable from your ad's
>       ca) as "trusted" in the system wide ldap confs
>       (/etc/openldap/ldap.conf or /etc/ldap/ldap.conf).
>
>     - depending upon your ad schema you might need to remap some attributes
>       to what the libnss-ldap libraries want them to be.  The ubuntu page
>       has some details on that (nss_map_attribute).  In more flexible
>       environments you can actually use these to do some fancy service
>       tricks (eg: different shell/homedir for sftp only hosts).
>
>     Some other tips:
>
>     - make sure you can do all these steps with the command line ldapsearch
>       utility first
>
>     - adsi edit (or some such - should be available in mmc) is the windows
>       utility to browse it's ldap store
>
>     - use nscd or one of the other tools I mention below to cache ldap data
>
>     So, following all those goodies, you should hopefully be able to get
>     ldap only id mapping and authentication going.
>
>     You can also tell samba (or apache, freeradius, etc.) to use those
>     details for id mapping and authentication, again avoiding the need for
>     kerberos entirely.  Have a look at the ldap settings within smb.conf for
>     details.  In all cases, tls/ssl is your friend.
>
>     Hope that helps,
>
>     Brian
>
>     [1] [6]https://help.ubuntu.com/community/ActiveDirectoryHowto
>
>     [2] [7]http://linux.die.net/man/5/pam_ldap
>
>     AD may very well be doing a kerberos auth behind the scenes when you
>     bind to its ldap, but that doesn't really matter.  That's a common way
>     for people to configure openldap as well - use kerberos as the password
>     hash store, but then you need a service ticket for openldap ...
>
>     [3] As an aside, there are also alternatives to libnss-ldap now
>     including: nslcd, sssd.  I think sssd is the more preferred one
>     nowadays.  Basically, they make a user program responsible for doing all
>     ldap lookups so that you can save some shared memory and protect the
>     proxy user's credentials.  Really though, the sort of stuff you'll be
>     querying in ldap is more or less "public" data as far as the rest of the
>     system is concerned anyways, so I wouldn't be too concerned with that
>     unless you've given the proxy user some ridiculous rights.  That goes
>     for openldap, opendirectory, whatever as well.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]