[Samba] Lessons learned

[Vijay Avarachen]

Hello,
     I would like to share few things I have learned over time in my attempt
to integrate all my Linux clients to an existing corporate Windows 2000
Active Directory (AD).  I am a Linux admin for a small division in a large
company and do not posses any special rights as far as AD goes.  I ONLY have
privileges on my division part of the tree in AD.

Goals:
- Integrate all Linux client to existing AD so the AD Dynamic DNS will
register hostnames
- Enable AD users to logon to Linux clients.  No users should be maintained
in local passwd files.
- Seem less samba share access from Windows.

I have accomplished all the goals listed above and here are a few things
that I learned:

- Distro
After much trial and error, I learned that the version of Samba shipped with
RHEL 3.0 is not very reliable when it comes to handling sites with large
amount of users.  Regardless of the idmap back end, winbind will die.  I
have standardized on RHEL 4.0 for workstations, Gentoo for back end servers.

- IDMAP
My initial attempts to achieve above listed golas used local tdb files for
keeping track of idmaps.  As our Linux environment grew from two
workstations to 13, and users started to move files around, all sort of
permission issues started to appear.  This happens because if you use local
tdb files for idmapping, the user might not get assigned the same UID, GID
on all the Linux hosts.  Even if you have a small userbase in AD, I highly
recomment using LDAP for idmap backend.

- IPTABLES
In RHEL place the following rules to enable Samba related activity
(/etc/sysconfig/iptables).  You might want to consider tightening the rules
further using -s (source).
#Winbindd
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j
ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j
ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j
ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j
ACCEPT

- TESTPARM
/usr/bin/testparm (RHEL) is your friend.  Every time you make changes to
smb.conf, use it to verify your changes.  Also smb.conf man
pages<http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html>are
crucial.

- RPMS
You will need the following RPM's:
#Samba base
>= samba-3.0.10-1.4E.2
>= samba-client-3.0.10-1.4E.2
>= samba-common-3.0.10-1.4E.2
# OpenLDAP for idmap backend
>= openldap-2.2.13-4
>= nss_ldap-226-10
>= openldap-clients-2.2.13-4
# Kerberos
krb5-libs-1.3.4-17

- Kerberos
/etc/krb5.conf is the key.  Without getting this file right you will not be
able to get a kerberos ticket from your AD.  The configuration of this file
really depends on your particular site.  You will know you got the contents
of this file right when you do kinit domain.user at YOUR.REALM and after
entering the password you get no errors.  Also doing klist should show you
the tickets and the expiration time 7 date.

- smb.conf Log Level
log level = 1 ads:10 auth:10 sam:10 rpc:10 winbind:5
Tail the log files and watch for errors.  (tail -f /var/log/samba/{smbd.log,
winbind.log,nmbd.log}

- AD Binding
Our corporate team does not allow anonymous binding to AD.  One easy was for
you to test this is to use either a command line utility like ldapsearch
(*nix) or Softerra LDAP browser (free).  Try connecting to your AD LDAP
anonymously, if you cannot then you need to use a non-privileged service
account with winbind for LDAP lookups. You might want to set this users
account to "Password never expires", or write a simple script that updates
settings on all Linux clients when the password changes.
wbinfo --set-auth-user=nonpriv.user%good.password

-OpenLDAP Privileged User
For OpenLDAP to serve as IDMAP backend, you must store a privileged users
credentials in secrets.tdb file.
In smb.conf I have:
ldap admin dn = cn=priv_ldap.user,o=company
ldap idmap suffix = ou=Idmap
ldap suffix = o=company
idmap backend = ldap:ldaps://ldapserver.company.com
#Keep the following consistant across all linux clients
idmap uid = 150000-550000
idmap gid = 150000-550000

To store the password for priv_ldap.user in secrets.tdb do:
smbpasswd -w good.password

priv_ldap.user is used to populate the idmap ou.  This user has no
relationship with AD LDAP lookup user.  One exists in AD ldap
(nonpriv.user) and the other in OpenLDAP (priv_ldap.user).  The user
only needs write
access to idmap ou.  So rather than using the ldap admin user, try setting
permissions in your slapd.conf file for a normal user with only write access
to idmap ou.

- NTP
Kerberos heavily depends on time.  Make sure your Linux clients synchronize
to the same time server as your AD Domain Controller (ADDC).  If not, you
will see error messages similar to "clock skew too great".

- Check List
[1] Ensure smb, winbind, nscd are not running.

[2] Delete/move all old tdb files.
/etc/samba/secrets.tdb
/var/cache/samba/*.tdb

[3] Add OpenLDAP server and AD Domain controller entries to /etc/hosts.
This is in case there is a DNS faliure.

[4] Ensure system time is same as your ADDC.  /etc/init.d/ntpd start
Gentoo NTP guide<http://www.gentoo.org/proj/en/infrastructure/config-ntp.xml>

[5] Edit your /etc/ldap.conf file and your /etc/openldap/ldap.conf file.
Make sure they are pointing to your OpenLDAP server.  A very nice guide to
get a basic OpenLDAP server up and running can be found at Gentoo
site<http://www.gentoo.org/doc/en/ldap-howto.xml>
.

[6] Edit your /etc/samba/smb.conf file.  Follow the Samba By
Example<http://www.samba.org/samba/docs/man/Samba-Guide/unixclients.html#adssdm>guide
closely.
Run testparm to make sure the file does not contain any errors.
[7] Store OpenLDAP priv_ldap.user password in secrets.tdb

[8] If anonymous binding is disabled on your AD, then setup auth user for
wbinfo.

[9] Edit /etc/krb5.conf

[10] Try getting kerberos ticket using AD domain admin account
kinit AD.admin at COMPANY.REALM
The REALM should always be upper-case (not sure why)
Verify ticket using klist command

[11] Moment of truth.  Time to join the Linux client to AD.
net ads join -w NA -U AD.admin -S addc.company.com
This command should not prompt your for a password if you got a kerberos
ticket for your AD.admin account in step [10 ] above.

[12] Edit /etc/nsswitch.conf to use AD as a source for user related info
passwd: files winbind
shadow: files winbind
group: files winbind

if you plan to add users to your LDAP (which won't be part of AD) and would
like to use those too, add ldap to above lines.  This is useful for service
accounts such as for a cluster queuing system.  I have placed such users
under DSA (Domain Service Accounts) and DSG (Domain Service Groups).

[13] Even though the Samba by example tells you to start nmbd, winbind and
then smbd in this order, I noticed that this is not important.  On the RHEL
4.x boxes I simply do
/etc/init.d/smb start (this starts smbd and nmbd)
/etc/init.d/winbind start

Before you can continue you need to make sure winbind was able to establish
trust with AD.  This is done by doing
wbinfo -t
However, be careful.  Our AD has thousands of users and groups, and because
of this and slow connection it takes a long time to establish this trust.
(long = 5-10 mins).
One easy way to know when winbind is done establishing the trust is to tail
to log file.  When it becomes less chatty, its a good time to test.
You should see something similar to:
~ $ wbinfo -t
checking the trust secret via RPC calls succeeded

[14] Once this trust is established, its time to see if the system sees AD
users and groups.  Use getent for this purpose.  What getent shows in its
output strictly depends on your nsswitch.conf.  If you only have 'files'
listed for passwd, group and shadow, you will only see local entries.  If
you specify 'winbind' then you should also see AD users.  'ldap' will show
OpenLDAP users (assuming you configured /etc/ldap.conf right).
getent passwd (get user list)
getent group (get group list)

Warning: Depending on the size of your AD, the output can be large.

[15] PAM time
Authentication in RHEL 4.x is all handled by Pluggable Authentication Module
(PAM).  I do not know much about PAM, just enough to get it working.  For AD
users to be able to authenticate, the only file I had to edit was
/etc/pam.d/system-auth  (this file is referenced by others services such as
/etc/pam.d/{ssh, login, gdm etc.}

I added the following lines:
#auth
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass
auth        sufficient    /lib/security/$ISA/pam_winbind.so use_first_pass
#account
account     [default=bad success=ok user_unknown=ignore]
/lib/security/$ISA/pam_ldap.so
account     [default=bad success=ok user_unknown=ignore]
/lib/security/$ISA/pam_winbind.so
#password
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    sufficient    /lib/security/$ISA/pam_winbind.so use_authtok
#session
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_ldap.so

Couple of things to keep in mind:
* Depending on what you set 'template shell' in smb.conf, that is what the
users will get by default.
* Depending on what you set 'template homedir' in smb.conf, that is what the
users home directory will be when he/she logs in.  In system.auth there is a
way you can set it to create the home directories automatically.  Search for
mkhomedir parameter.
* if you do not get a valid output for getent passwd user.name authentication
is not going to work
# getent passwd vijay.avarachen
vijay.avarachen:*:161167:150000:VijayAvarachen:/home/NA/vijay.avarachen:/bin/bash


Once you have everything working, I recommend turning on nscd.  Nscd will
never cache passwords.  Passwords are always verified live against AD.

I hope this helps people out there....I know there is more I can write
....which I probably will.  At my company I have my Linux environment well
integrated with AD.  I have a NAS device serving home directories to all
Linux hosts, so users get the same desktop settings no matter what
workstation they use (roaming profile of sorts).  Also I am able to tighten
security by issuing all users RSA keys for ssh authentication. Also I am
able to control who can SSH into a server/workstation by using AllowGroups
parameter in sshd_conf file.


There are also few issues that I am trying to figure out with GDM, KDM.

Thanks,
Vijay Avarachen
:wq

--
"Knowledge is the only wealth that grows as you spend it, and diminishes as
you save it."
-- ancient Sanskrit saying