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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba