Samba & Active Directory

From SambaWiki

Jump to: navigation, search

Contents

How much AD integration do you want?

You can get Linux Login's and Samba Shares to both authenticate against AD. For that, keep reading this document.

If, instead, you want to have Linux Login's authenticated either natively or against OpenLDAP, but have Samba Shares authenticated by AD, while still using UID/GID's defined internally or by OpenLDAP, read this: Samba, Active Directory & LDAP

Which steps must be done to run Samba with AD-Integration

Prerequisites

  1. Software
    • Samba > 3.0.20
    • Kerberos MIT/Heimdal
    • ntp
    • often cups-Server
  2. Permissions/Users
    • root-user on the server
    • an AD user with the permission to join AD (Explanation).

Steps

  1. The time between DC's and the Samba server must be in sync
    • use ntp
  2. configure your Kerberos environment kinit must be running fine
  3. configure your smb.conf
    • security = ADS
  4. join into the domain
    • kinit
    • net ads join
  5. start the services
    • nmbd
    • smbd
    • winbindd

Slightly Fuller Explanation

Taken from http://ask.jara23.co.uk (by the Author)

To connect Linux(specifically RHEL) To Active Directory, you must have Kerberos (krb5), Winbind and Samba installed. Samba must be newer than 3.08, or it doesn't work. It will also be helpful during the testing to take the firewall down, to facilitate things working. A working firewall will be posted as soon as one has been worked out.. You will also need to configure PAM and nsswitch to get it authenticating against the Active Directory.

system-Config-authentication

On RHEL system, (or, presumably on Fedora core systems), you can use the system-config-authentication module. Simply chose winbind, and remember to chose "use kerberos". The Domain will be your windows Domain, and the Realm will be your ADS realm (eg WINDOWS.JARA23.CO.UK). You should then be able to click "join domain". This should connect you happily to the domain. Unfortunately, you won't see any errors until you exit the program. Normally, the biggest problem is with clock skew, ensure your clock time matches that of your ActiveDirectory server (for example by using ntpdate my.activedirectory.time.server.com). A fully populated and properly configured DNS system (including SRV records for your realm) for your LAN will save you many WTF! moments.

Setting Up Kerberos

The first thing to do is to set up the kerberos keys so that they work. Remember that kerberos is time-dependent, so you may have to make sure that the machine time is correct using a protocol like NTP.

Windows Servers should automatically update their clocks and Windows Workstations (2000 and later) synchronize their clocks to the Active Directory server. To emulate this behavior in Linux add the line server ad-server-name in your /etc/ntp.conf file and comment out all other server lines.

Below is all you should need in your krb5.conf file.

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = yes

[appdefaults]
pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
}

Save the file.

If you have problems joining the domain, you can determine if the KDC and the DCs generally are reachable with a command like:

[blah@host ~]# host -t srv _kerberos._tcp.windows.jara23.co.uk
_kerberos._tcp.windows.jara23.co.uk has SRV record 0 100 88 your-dc-name.windows.jara23.co.uk.

If the output does not return an SRV record then you have a problem with DNS or with connectivity that you need to resolve before you can join the domain.

Setting up Samba

Samba is the software that allows you to connect Linux and UNIX clients to a Window's domain in the same way as you would a Windows 2000/XP machine. There are three important components, smbd, nmbd, and winbind, which all use the same configuration file: /etc/samba/smb.conf. Check the example configuration file below:

#GLOBAL PARAMETERS
[global]
   workgroup = MIDGARD
   realm = WINDOWS.JARA23.CO.UK
   preferred master = no
   server string = Linux Test Machine
   security = ADS
   encrypt passwords = yes
   log level = 3
   log file = /var/log/samba/%m
   max log size = 50
   printcap name = cups
   printing = cups
   winbind enum users = Yes
   winbind enum groups = Yes
   winbind use default domain = Yes
   winbind nested groups = Yes
   winbind separator = +
   idmap uid = 600-20000
   idmap gid = 600-20000
   ;template primary group = "Domain Users"
   template shell = /bin/bash

[homes]
   comment = Home Direcotries
   valid users = %S
   read only = No
   browseable = No

[printers]
   comment = All Printers
   path = /var/spool/cups
   browseable = no
   printable = yes
   guest ok = yes

A few important switches that might need a bit of explanation.

  • winbind use default domain = Yes removes the domain prefix from usernames, so you can login as Username instead of DOMAIN\Username or in some cases DOMAIN+Username (see next explanation).
  • winbind separateor = + : This is the seperator used to separate domain from username. Generally in documentation you will find this set to +. When you run testparm this will throw a warning, but that should be okay. It will mean that when you list the users you will see them in the form "MIDGARD+phb".
  • idmap uid = 600-2000 and idmap gid = 600-2000 set where the users from the AD will map onto the local system. the starting value for this should be the highest number of the last local user on your system. for example: if in your passwd the last user listed is "bob" with a uid of "740," the starting value of your idmap entries should probably be about 800. if local uid's and gid's overlap mapped ad uid's and gid's, then the user will be evaluated in accordance with nsswitch.conf order. setting your idmaps lower than 100 is ill advised: This can lock you out of your root account if your nsswitch order specifies a query to winbindd first.
  • template primary group = "Domain Users" sets the default group for users coming into the system. not required for most windows 2003 domain controllers unless they are in "mixed mode."
  • template shell = /bin/bash gives the default shell to users logging onto your system. As this is not filled in by Active Directory, winbind does it all for you, locally.
  • winbind enum groups and winbind enum users allow the command "getent" to return with groups and users respectively.

winbind enum users and groups should be used with caution in active directories greater than 200 users or groups, as enumeration is an expensive process and likely to timeout and cause login failures. during login, the full passwd and group will be "enumerated" every time from your active directory server. enumeration is not required for a successful login.

Now, test the parameters file, and correct any syntax errors, using the command "testparm". It should print out that everything is okay, and a warning about the + sign possibly causing problems with domain joins. This can be safely ignored. The next thing is to start the services. All the documents on the web suggest starting them in order NMB, SMB, then Winbind. On Fedora Core 7 (and redhat enterprise linux 5), using the service smbd start and service windbind start works fine. prior versions will require an additional "d" on winbind (service winbindd)

Now to join your machine to the active directory. You will need the user-name and password to a Domain Administrator account to do this. The command you need to join the domain is net ads join -U sadwrn. This should then ask you for a password, and print a domain join notice.

To check that you have succesfully joined the domain, there are several things you can test.

  • net ads testjoin Test the connection to the Active Directory.
  • wbinfo -u Should now list all the members of the domain. TIP You might see a laod of machine names followed by $. eg myserver$. This is normall. You might want to try piping the output to more. a wbinfo -u may fail once or twice if your directory is large.
  • wbinfo -g Should now list all the groups available in the domain. You might note that if you have more than one domain, that the members of the other domain will appear in the form "DOMAIN+mygroup". This is normal, and expected! the command may also fail once or twice if your directory is large.
  • wbinfo -a username%password checks to see if username using password can connect to the domain. Remember the password, you have to type it as part of the command; it won't ask you for it later.
  • should wbinfo fail to return all groups or users in the active directory, simply increase the idmap gid upper boundary and restart winbind and SMB until all users and groups are produced in the list.

At this point you are presumably authenticating against the AD. authentication failures have the potential to lock your Active Directory account.

Adding this list to the password list.

The next step is to get the passwd command to check the winbind list for usernames and groups. This is fairly straight forward as it only involves changing one file, /etc/nsswitch.conf and at that fairly minimally. Of course, backup this file before changing it.

passwd: files winbind
shadow: files winbind
group: files winbind

#hosts: db files nisplus nis dns
hosts: files dns wins

# Example - obey only what nisplus tells us...
#services: nisplus [NOTFOUND=return] files
#networks: nisplus [NOTFOUND=return] files
#protocols: nisplus [NOTFOUND=return] files
#rpc: nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks: nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers: db files
netmasks: files
networks: files dns
protocols: db files
rpc: files
services: files

netgroup: files

publickey: nisplus

automount: files
aliases: files nisplus

As you can see, the file is configured to check the local passwd file first. This is so that things like system and root accounts don't lag waiting for a response from the Active Directory, when won't be forthcoming. It also ensures that if there is a problem, Root and services will still function (for example, samba can't look up it's own account over Active Directory during startup!).

Note that the following files (and symlinks) must be present in the system /lib directory:

libnss_winbind.so
libnss_winbind.so.2 -> libnss_winbind.so
libnss_wins.so
libnss_wins.so.2 -> libnss_wins.so

If you compiled from source you will probably have to copy these files manually after `make install` You should now be able to run getent passwd and see the local password list, and on the end of it, those that have been imported from the Active Directory. Now all that remains is setting up PAM authentication.

Setting up PAM Authentication for Active Directory.

ALERT! Before you start, backup you you /etc/pam.d directory. Failure at this stage can lock the entire machine. Log in a root account on a virtual terminal, and LEAVE IT LOGGED IN until such time as you have tested the new configuration. Perhaps log in TWO root accounts incase of mistakes.

On RedHat, the PAM configuration exists in the /etc/pam.d/system-auth and /etc/pam.d/password-auth files. These files are responsible for directing the services that require authentication to the right mechanism to get a response. Change the files as follows:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_unix.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
account required /lib/security/$ISA/pam_permit.so

password requisite /lib/security/$ISA/pam_cracklib.so retry=3 type=
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
password required /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session required /lib/security/$ISA/pam_winbind.so use_first_pass

Save the file, and change to another virtual terminal. Try logging in as a Member of the Active Directory. This should work, though you WILL see an error about missing home-directory (don't worry about that, we'll fix that later). If you have had a a previous user account on that machine that matches the log-in from the Active Directory, you will need to comment it out. (comment, not delete, that way you can restore if things go wrong). Check as many users as you can, until you feel comfortable that the mechanism works. ALERT! Remember to ensure that ROOT can still log in.

Home Directories

Once all the above is working, you might be tempted to reboot, and try to log in. Bad Idea. Currently no users have home-directories.

Creating home directories manually

By default the home directories are created under /home/DOMAIN/username. So, in our example, user phb's home directory will be found in /home/MIDGARD/shadowknight. You can specify the root of the home directory with the "template homedir = /home/%U" (or similar) option; this example is similar to *nix local user home directory structure and eliminates the (%D reference and) domain name from users' home directorys' paths. Since we're using the "winbind use default domain = yes" option, we're only planning to resolve the accounts for one domain anyway; there is no danger of account name overlap among trusted domains. Another Gotcha is that there is no group "ShadowKnight". So when you create the directory, as root, and then attempt to chown (shadowknight:shadowknight) it, it throws an error. What you need to do is to create the Directory MIDGARD, then create the directory shadowknight, then chown -R shadowknight:"Domain Users" shadowknight. This, of course, is a bit of a security problem. It leaves the home directory open to anyone in "Domain Users" unless you remove permissions from that group.Implementation of Posix ACLs on the underlying file system partition also makes management and inheritance of complex ACLs much easier. With proper implementation of Posix ACLs (including default ACLs) and no security restrictions in smb.conf, Samba very closely approximates NT ACLs (including full configuration from within Windows Explorer Security tabs).

---ShadowKnight 06:37, 15 September 2006 (CDT)

If you'd rather have users home directories generated on the fly when they first login to your Linux machine, add this line of code in /etc/pam.d/system-auth.

session required /lib/security/pam_mkhomedir.so

through the specification of skel= you can also control special skel files provided to dc users. --Nimbius 13:11, 31 October 2006 (CST)

Authenticating share users and groups against active directory

Yeah, this one took me about a day too.

[Pictures]

   comment = Directory for storing pictures by jims users
   path= /usr/local/pictures
   Valid Users =@NETWORK+archival NETWORK+billybob NETWORK+jane
  ; public=no
   writable=yes
   browseable=yes

So what has this done? @NETWORK+archival gives any member of the archival group on NETWORK access to this share. NETWORK+billybob NETWORK+jane gives billybob and jane, both single user members of NETWORK, access to this share.


--Nimbius 13:11, 31 October 2006 (CST)

Advanced Configuration

Windows 2003 R2 Active Directory

In the case that your AD is running on Windows 2003 R2 and the UNIX integration is enabled (RFC2307 schema), you can use the information in the AD for the Unix accounts provided by winbind.

Thus all user information (Windows & Unix) is maintained in a single place (the Active Directory) and you don't have to bother about ID mapping any more.

Configuring Windows

I am still working on that ...

Notes:

  • Samba ignores the member list of Unix groups but rather follows the Windows group relationships (including nested groups). If you also use LDAP/NIS somewhere else, you must continue to fill in the Unix group lists to match the Windows group membership information. This is due to the stupid design of the Windows SFU extension and Samba is doing the right thing.

Configuring Samba

The Samba configuration (tested on 3.0.24) should contain these values:

[global]
passdb backend = tdbsam
idmap backend = ad
idmap uid = 100-20000000
idmap gid = 100-20000000
winbind nss info = rfc2307

Notes:

  • passdb backend is not strictly required, but recommended to manage the BUILTIN and LOCAL accounts
  • the idmap uid and idmap gid ranges should be chosen to not conflict with existing Unix users on the Unix server but to include all existing Unix IDs already in your AD
  • You must make sure that the primary group of the Unix users in the AD is also Unix enabled (with a GID) (A user whose primary group is not also a Unix group will not show up on Unix at all !)
  • winbind nss info instructs Samba to use the RFC2307 schema in the AD for the NSS information (shell, home dir ...)

Please note that from 3.0.25 on these values look different as one needs to use the new idmap stuff !

--Schlomo 05:59, 1 May 2007 (CDT)

access control

not every domain user should be allowed to gain access to every linux box on the network. in pam, winbind can be configured to allow only a certain group access to the server example:

    auth required /lib/security/$ISA/pam_winbind.so use_first_pass require_membership_of=vpn-informationtechnology

now, only members of the AD group vpn-informationtechnology can access this server. multiple winbind entries in pam can allow multiple groups access to a single server as normal users. whitespaces arent allowed in group names.

access.conf as well as /etc/sudoers can also be controlled using active directory groups and users. Whitespace in the group name needs to be escaped with a backslash.

permissions

AD users and groups may be designated as file and directory owners, and whitespace may be used in group names however must be escaped by backslash. chown, chgrp,setfacl, and getfacl all function with active directory users and groups.

password changes

it is possible to change your password using samba AD integration, but not recommended. it results in a curious condition in that seemingly two passwords become assigned to one username.

both the old, as well as the new password come into effect and are accepted by linux as well as some windows systems utilizing AD as an authentication mechanism (ex: altiris). Windows logon however only accepts the new password assigned by the user.

the madness continues with windows' ability to "extinguish" silently the old password... Once a linux user logs back into their windows system with this new password (assigned in linux), the old password automagically becomes null and void; no longer existing for use anywhere.

Personal tools