Great guide Vijay!

Thank you for sharing.

Cheers,
Henrik
18 dec 2005 kl. 21:30 skrev 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 [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

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

Reply via email to