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