Re: Complete migration from Scientific Linux with new features (Samba+AD/Winbind)

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: 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:

auth ~ # cat /etc/krb5.conf
[libdefaults]
	default_realm = IF.UFRJ.BR
	dns_lookup_realm = true
	dns_lookup_kdc = true
	ticket_lifetime = 24h
	renew_lifetime = 7d
	forwardable = true
	verify_ap_req_nofail = false

[appdefaults]
	kinit = {
		renewable = true
		forwardable = true
	}

[realms]
# use "kdc = ..." if realm admins haven't put SRV records into DNS

	IF.UFRJ.BR = {
		kdc = ad.if.ufrj.br
		default_domain = if.ufrj.br
	}
	
[domain_realm]
	.if.ufrj.br = IF.UFRJ.BR
	if.ufrj.br = IF.UFRJ.BR

[logging]
	default = FILE:/var/log/krb5libs.log
	kdc = FILE:/var/log/krb5kdc.log
	admin_server = FILE:/var/log/kadmind.log
	kdc_rotate = {
		period = 1d
		version = 10
	}

Other files that may interest:

/etc/nss-ldapd.conf
uri 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

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.

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] https://help.ubuntu.com/community/ActiveDirectoryHowto
> [2] 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.
> 
> Vinícius Ferrão <[email protected]> 2011-11-01 17:24:
>> As I can understand we need Kerberos 5 for authentication and LDAP acting
>> only as a directory service with UID, GID, home dir and etc.
>> []'s
>> On Nov 1, 2011, at 5:11 PM, gregorcy wrote:
>> 
>>   On Sun, Oct 30, 2011 at 1:55 PM, Brian Kroth <[1][email protected]>
>>   wrote:
>> 
>>     gregorcy <[2][email protected]> 2011-10-29 10:52:
>> 
>>          What's missing: OpenLDAP replication from AD? Is this possible?
>>       Is this
>>          needed? Since I want another machines (running Linux) to
>>       authenticate it
>>          will be a good idea only ONE machine get information from AD and
>>          everyone else authenticate natively on this Gentoo Machine.
>> 
>>        No this is not needed.  If you are in a mixed environment (I think)
>>       it
>>        is much easier to just use AD as the one directory service and join
>>       all
>>        your linux boxes to it.  As long as your idmap ranges match your
>>       users
>>        will have the same uid on all boxes.
>> 
>>     I agree with this except for the need to "join all your linux boxes".
>>      AD is really just ldap+kerberos.  Most of the time you don't need the
>>     headache of kerberos and can just use the ldap component.  Modern AD
>>     schemas include all the of necessary attributes support for having
>>     Linux clients talk to it directly for uid/gid mapping, which is much
>>     nicer since it avoids the complexity of any samba requirements when
>>     you don't need them (eg: mail, web, etc.).
>> 
>>   So if he is using samba + winbind I don't see how you can not join all
>>   your machines to the AD.  Actually I would be really interested in how
>>   you configure your machines just using the ldap component.  I have been
>>   using winbind for the last couple of years but if there is a better way
>>   I would be interested in learning how it works.
>> 
>> 
>> References
>> 
>> Visible links
>> 1. mailto:[email protected]
>> 2. mailto:[email protected]
> 
>