Difference between revisions of "Active Directory Integration"

From ArchWiki
Jump to: navigation, search
(Major rewrite of the article to fix some workflow issues, and improve the quality of the article.)
(44 intermediate revisions by 12 users not shown)
Line 1: Line 1:
[[Category:Networking (English)]]
+
[[Category:Networking]]
This guide explains how to include ArchLinux into an existing Windows Active Directory.
+
{{Warning|Because Arch Linux is a rolling release distribution, it is possible that some of the information in this article could be outdated due to package or configuration changes made by the maintainers. Never blindly follow these or any other instructions. When the instructions say to edit or change a file, consider making a backup copy. Check the date of the last revision of this article.}}
  
== Introduction ==
+
A key challenge for system administrators of any datacenter is trying to coexisting in Heterogeneous environments. By this we mean the mixing of different server operating system technologies (typically Microsoft Windows & Unix/Linux). User management and authentication is by far the most difficult of these to solve. The most common way of solving this problem is to use a Directory Server. There are a number of open-source and commercial solutions for the various flavors of *NIX; however, few solve the problem of interoperating with Windows. Active Directory (AD) is a directory service created by Microsoft for Windows domain networks. It is included in most Windows Server operating systems. Server computers on which Active Directory is running are called domain controllers.
  
A key challenge for system administrators of any datacenter is trying to coexisting in Heterogeneous environments. By this we mean the mixing of different server operating system technologies (typicall Microsoft Windows & Unix/Linux). User management and authentication is by far the most difficult of these to solve. The most common way of solving this problem is to use a Directory Server. There are a number of open-source and commercial solutions for the various flavors of *NIX; however, few solve the problem of interoperating with Windows. Active Directory (AD) is a directory service created by Microsoft for Windows domain networks. It is included in most Windows Server operating systems. Server computers on which Active Directory is running are called domain controllers.  
+
[[Wikipedia:Active Directory|Active Directory]] serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a network of Windows domain type, assigning and enforcing security policies for all computers in a network and installing or updating software on network computers. For example, when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password and specifies whether he or she is a system administrator or normal user.
  
Active Directory serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a network of Windows domain type, assigning and enforcing security policies for all computers in a network and installing or updating software on network computers. For example, when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password and specifies whether he or she is a system administrator or normal user.[1]
+
Active Directory uses [[Wikipedia:Ldap|Lightweight Directory Access Protocol (LDAP)]] versions 2 and 3, [[Wikipedia:Kerberos_(protocol)|Kerberos]] and DNS. These same standards are available as linux, but piecing them together is not an easy task. Following these steps will help you configure an ArchLinux host to authenticate against an AD domain.
  
Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Kerberos and DNS. These same standards are available as linux, but piecing them together is not an easy task. Following these steps will help you configure an ArchLinux host to authenticate against an AD domain.
+
This guide explains how to integrate an Arch Linux host with an existing Windows Active Directory domain.  
 +
Before continuing, you must have an existing Active Directory domain, and have a user with the appropriate rights within the domain to: query users and add computer accounts (Domain Join).  
  
=== Requirements ===
+
This document is not an intended as a complete guide to Active Directory nor Samba. Refer to the resources section for additional information.
  
Before starting, you must have an existing Active Directory domain, and have the appropriate rights within the domain to query users, and add computer accounts (Domain Join).
+
== Terminology ==
  
The following packages should also be installed:
+
If you are not familiar with Active Directory, there are a few keywords that are helpful to know.
* samba
+
* krb-5
+
* pam-krb5
+
* pam_pwcheck
+
* openntpd (or) ntp
+
  
<pre>
+
* '''Domain''' : The name used to group computers and accounts.
pacman -S samba pam-krb5 pam_pwcheck openntpd
+
* '''SID''' : Each computer that joins the domain as a member must have a unique SID or System Identifier.
</pre>
+
* '''SMB''' : Server Message Block.
 +
* '''NETBIOS''': Network naming protocol used as an alternative to DNS. Mostly legacy, but still used in Windows Networking.
 +
* '''WINS''': Windows Information Naming Service. Used for resolving Netbios names to windows hosts.
 +
* '''Winbind''': Protocol for windows authentication.
 +
== Configuration ==
 +
=== Active Directory Configuration ===
 +
{{Warning|This section has not been validated. Proceed with caution}}
  
 +
==== Updating the GPO ====
 +
It may be necessary to disable ''Digital Sign Communication (Always)'' in the AD group policies. Dive into:
  
=== Preparation of the Windows AD policy ===
+
{{ic|Local policies}} -> {{ic|Security policies}} -> {{ic|Microsoft Network Server}} -> {{ic|Digital sign communication (Always)}} -> activate {{ic|define this policy}} and use the {{ic|disable}} radio button.
** NOTE: This step has not been validated
+
  
It is necessary to disable ''Digital Sign Communication (Always)'' in the AD group policies. Dive into:<p>
+
If you use Windows Server 2008 R2, you need to modify that in GPO for Default Domain Controller Policy -> Computer Setting -> Policies -> Windows Setting -> Security Setting -> Local Policies -> Security Option -> ''Microsoft network client: Digitally sign communications (always)''
  
Local policies -> Security policies -> Microsoft Network Server -> Digital sign communication (Always) -> activate "define this policy" and use the '''disable''' radio button</p>
+
=== Linux Host Configuration ===
  
 +
The next few steps will begin the process of configuring the Host. You will need root or sudo access to complete these steps.
  
If you use Windows Server 2008 R2, you need to modify that in GPO for Default Domain Controller Policy -> Computer Setting -> Policies -> Windows Setting -> Security Setting -> Local Policies -> Security Option -> ''Microsoft network client: Digitally sign communications (always)''
+
=== Installation ===
<p> </p>
+
This is all you have to do in Windows. Let's go on with Arch Linux.
+
  
== Configuration ==
+
[[Pacman|Install]] the following packages:
Please check your /etc/hosts file! It is important for it to be correctly configured. If you have a dual boot system on a machine, you have to use a different hostname and netbios name for the linux configuration, or the protected connection between windows and the domain controller will result broken.
+
* {{Pkg|samba}}
 +
* {{Aur|pam-krb5}} ---- AUR
 +
* {{Pkg|pam_pwcheck}}
 +
* {{Pkg|openntpd}} (or) {{Pkg|ntp}}
  
In our example:<br>
+
=== Updating DNS ===
127.0.0.1    MACHINE-NAME.PARADISE.COM    MACHINE-NAME<br>
+
192.168.0.1  ADAM.PARADISE.COM            ADAM<br>
+
192.168.0.2  EVE.PARADISE.COM              EVE<br>
+
  
=== Samba / Winbindd startup ===
+
Active Directory is heavily dependent upon DNS. You will need to update {{ic|/etc/resolv.conf}} to use one or more of the Active Directory domain controllers:
 +
{{hc|/etc/resolv.conf|
 +
nameserver <IP1>
 +
nameserver <IP2>
 +
}}
 +
Replacing <IP1> and <IP2> with valid IP addresses for the AD servers. If your AD domains do not permit DNS forwarding or recursion, you may need to add additional resolvers.
  
Arch Linux implements samba and winbind as a single script in /etc/rc.d/samba
+
{{Note|If your machine dual boots Windows and Linux, you should use a different DNS hostname and netbios name for the linux configuration if both operating systems will be members of the same domain.}}
  
The daemons started by /etc/rc.d/samba are configured in the file /etc/conf.d/samba.
+
=== Configuring NTP ===
 +
Read [[NTPd]] or [[OpenNTPD]] to configure a NTP service. Note that OpenNTPD is no longer maintained.
  
<pre>
+
On the configuration, use the IP addresses for the AD servers. Alternatively, you can use other known NTP servers provided the Active directory servers sync to the same stratum. However, AD servers typically run NTP as a service.
##### /etc/conf.d/samba #####
+
#SAMBA_DAEMONS=(smbd nmbd)
+
SAMBA_DAEMONS=(smbd nmbd winbindd)
+
</pre>
+
  
=== Heimdal / Kerberos - /etc/krb5.conf ===
+
Ensure the daemon is configured to '''sync automatically on startup'''.
<p> Let's assume that your AD is named paradise.com. Let's further assume your AD is ruled by two domain controllers, the primary and secondary one, which are named adam and eve, adam.paradise.com and eve.paradise.com respectively. Their IP adresses will be 192.168.0.1 and 192.168.0.2 in this example.  Take care to watch your syntax; upper-case is very important here.</p>
+
 
<pre>
+
=== Kerberos ===
##### /etc/krb5.conf ####
+
 
 +
Let's assume that your AD is named example.com. Let's further assume your AD is ruled by two domain controllers, the primary and secondary one, which are named PDC and BDC, pdc.example.com and bdc.example.com respectively. Their IP adresses will be 192.168.1.2 and 192.168.1.3 in this example.  Take care to watch your syntax; upper-case is very important here.
 +
 
 +
{{hc|/etc/krb5.conf|<nowiki>
 
[libdefaults]
 
[libdefaults]
         default_realm = PARADISE.COM
+
         default_realm = EXAMPLE.COM
 
clockskew = 300
 
clockskew = 300
 
ticket_lifetime = 1d
 
ticket_lifetime = 1d
 +
        forwardable    =      true
 +
        proxiable      =      true
 +
        dns_lookup_realm =      true
 +
        dns_lookup_kdc  =      true
 
 
 
[realms]
 
[realms]
PARADISE.COM = {
+
EXAMPLE.COM = {
kdc = 192.168.0.1
+
kdc = PDC.EXAMPLE.COM
kdc = 192.168.0.2
+
                admin_server = PDC.EXAMPLE.COM
default_domain = PARADISE.COM
+
default_domain = EXAMPLE.COM
 
}
 
}
 
 
 
 
[domain_realm]
 
[domain_realm]
.paradise.com = PARADISE.COM
+
        .kerberos.server = EXAMPLE.COM
paradise.com = PARADISE.COM
+
.example.com = EXAMPLE.COM
paradise = PARADISE.COM
+
example.com = EXAMPLE.COM
 +
example = EXAMPLE.COM
  
 
[appdefaults]
 
[appdefaults]
Line 92: Line 103:
  
 
[logging]
 
[logging]
default = SYSLOG:NOTICE:DAEMON
+
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/kdc.log  
+
kdc = FILE:/var/log/kdc.log
</pre>
+
        admin_server            = FILE:/var/log/kadmind.log
'''Update:'''<br>
+
</nowiki>}}
Heimdal 1.3.1 deprecated DES encryption which is required for AD authentication before Windows Server 2008. You'll probably have to add <pre>allow_weak_crypto = true</pre> to the {{Ic|[libdefaults]}} section.
+
  
 +
{{Note|Heimdal 1.3.1 deprecated DES encryption which is required for AD authentication before Windows Server 2008. You'll probably have to add {{bc|1=allow_weak_crypto = true}} to the {{Ic|[libdefaults]}} section.}}
  
Inside an AD, it is important that all machines run the same system time. To synchronize the time run:
+
==== Creating a Kerberos Ticket ====
<pre>
+
Now you can query the AD domain controllers and request a kerberos ticket ('''uppercase is necessary'''):
/usr/bin/ntpdate adam.paradise.com
+
{{bc|kinit administrator@EXAMPLE.COM}}
</pre>
+
  
Now you can query the AD domain controllers for a ticket with the following commands ('''uppercase is necessary'''):
+
You can use any username that has rights as a Domain Administrator.
<pre># kinit ADMINISTRATOR@PARADISE.COM</pre>
+
  
<p>You´ll now be asked for the password. In case it matches, you'll be returned to the console.</p>
+
==== Validating the Ticket ====
 +
Run '''klist''' to verify you did receive the token. You should see something similar to:
 +
{{hc|# klist|
 +
Ticket cache: FILE:/tmp/krb5cc_0
 +
Default principal: administrator@EXAMPLE.COM
 +
 +
Valid starting    Expires          Service principal
 +
02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM
 +
        renew until 02/05/12 21:27:47
 +
}}
 +
=== Samba ===
 +
Samba is a free software re-implementation of the SMB/CIFS networking protocol. It also includes tools for Linux machines to act as Windows networking servers and clients.
  
=== PAM configuration for login ===
+
{{Note|The configuration can vary greatly depending on how the Windows environment is deployed. Be prepared to troubleshoot and research}}
<p>Now we have to change /etc/pam.d/login so it sends its request to the AD controllers. In case of logins, PAM should first ask for AD accounts, and for local accounts if no matching AD account was found. Therefore, we add entries to include pam_winbindd.so into the authentication process. Furthermore, we include pam_mkhomedir.so. If an AD user logs in, /home/paradise/user will be created automatically.</p>
+
<pre>
+
#### /etc/pam.d/login ####
+
#%PAM-1.0
+
auth    sufficient    pam_unix2.so
+
auth    required      pam_winbind.so use_first_pass use_authtok
+
auth    required      pam_securetty.so
+
auth    required      pam_nologin.so
+
auth    required      pam_mail.so
+
account  sufficient    pam_unix2.so
+
account  sufficient    pam_winbind.so use_first_pass use_authtok
+
password required      pam_pwcheck.so
+
password sufficient    pam_unix2.so
+
password sufficient    pam_winbind.so use_first_pass use_authtok
+
session  required      pam_mkhomedir.so skel=/etc/skel/ umask=0022
+
session  sufficient    pam_unix2.so
+
session  sufficient    pam_winbind.so use_first_pass use_authtok
+
session  required      pam_limits.so
+
</pre>
+
<p>If you like to allow AD users to login into GDM, you have to do the same for /etc/pam.d/gdm. You may try to change other /etc/pam.d/ rules for other apps, to allow them to authenticate AD users.</p>
+
  
=== Samba configuration for shares===
+
In this section, we will focus on getting Authentication to work first by editing the 'Global' section first. Later, we will go back and add shares.
<p> Samba is highly configurable. Take this example only as a rough idea, hardly polished. Here is what my /etc/samba/smb.conf looks like:</p>
+
 
<pre>
+
{{hc|/etc/samba/smb.conf|<nowiki>
#### /etc/samba/smb.conf ####
+
 
[Global]
 
[Global]
netbios name = archlinux
+
  netbios name = MYARCHLINUX
workgroup = PARADISE
+
  workgroup = EXAMPLE
realm = PARADISE.COM
+
  realm = EXAMPLE.COM
server string = archlinux
+
  server string = %h ArchLinux Host
map to guest = Bad User
+
  security = ads
idmap uid = 10000-20000
+
  encrypt passwords = yes
idmap gid = 10000-20000
+
  password server = pdc.example.com
winbind enum users = yes
+
  idmap uid = 10000-20000
winbind enum groups = yes
+
  idmap gid = 10000-20000
winbind gid = 10000-20000
+
winbind use default domain = Yes
+
winbind separator =+
+
os level = 20
+
 
+
# Theres no shell defined for users in AD, so I define a default shell to use
+
# Not sure if its even possible to define a shell in AD
+
template shell = /bin/bash
+
 
   
 
   
encrypt passwords = yes
+
  #idmap backend = rid
security = ads
+
password server = adam.paradise.com
+
preferred master = no
+
dns proxy = no
+
wins server = eve.paradise.com
+
wins proxy = no
+
  
admin users = @"NET+domain admins"
+
  winbind use default domain = Yes
force group = "PARADISE+domain admins"
+
  winbind enum users = Yes
inherit acls = Yes
+
  winbind enum groups = Yes
map acl inherit = Yes
+
  winbind nested groups = Yes
acl group control = yes
+
  winbind separator = +
 +
  winbind refresh tickets = yes
 +
  winbind gid = 10000-20000
  
load printers = no
+
  template shell = /bin/bash
debug level = 3
+
  template homedir = /home/%D/%U
use sendfile = no
+
 
+
  preferred master = no
[homes]
+
  dns proxy = no
comment = User´s homedirs
+
  wins server = pdc.example.com
path =/home/%U
+
  wins proxy = no
valid users = %S NET+%S
+
browseable = no
+
read only = no
+
  
[data] 
+
  inherit acls = Yes
comment = Data
+
  map acl inherit = Yes
valid users = %S net+%S
+
  acl group control = yes
path = /data
+
 
read only = no
+
  load printers = no
browseable = yes
+
  debug level = 3
+
  use sendfile = no
[Back-up]
+
</nowiki>}}
comment = Backup filer
+
path = /backup
+
read only = no
+
browseable = yes
+
valid users = @"NET+Domain Admins"
+
</pre>
+
  
 
We shall now explain to Samba that it shall use the PDC´s database for authentication queries. Again, we use winbindd which is a part of the samba package. Winbind maps the UID and GID of the AD to our Linux-machine. Winbind uses a Unix-implementation of RPC-calls, Pluggable Authentication Modules (aka PAM) and Name Service Switch (NSS) to allow Windows AD and users accessing and to grant permissions on the Linux-machine. The best part of winbindd is, that you don´t have to define the mapping yourself, but only define a range of UID and GID. That´s what we defined in smb.conf.
 
We shall now explain to Samba that it shall use the PDC´s database for authentication queries. Again, we use winbindd which is a part of the samba package. Winbind maps the UID and GID of the AD to our Linux-machine. Winbind uses a Unix-implementation of RPC-calls, Pluggable Authentication Modules (aka PAM) and Name Service Switch (NSS) to allow Windows AD and users accessing and to grant permissions on the Linux-machine. The best part of winbindd is, that you don´t have to define the mapping yourself, but only define a range of UID and GID. That´s what we defined in smb.conf.
To include Winbindd into NSS calls, edit /etc/nsswitch.conf. Add winbind to the lines as shown here:
+
 
<pre>
+
Update the samba configuration file to enable the winbind daemon
#### /etc/nsswitch.conf ####
+
 
passwd:            files winbind
+
{{hc|/etc/conf.d/samba|<nowiki>
shadow:            files winbind
+
##### /etc/conf.d/samba #####
group:            files winbind
+
#SAMBA_DAEMONS=(smbd nmbd)
</pre>
+
SAMBA_DAEMONS=(smbd nmbd winbindd)
 +
</nowiki>}}
 +
 
 +
Next, configure {{ic|samba}} to startup at boot. Read [[Daemons]] for more details.
  
 
== Starting and testing services ==
 
== Starting and testing services ==
Line 209: Line 190:
 
Hopefully, you have not rebooted yet! Fine. If you are in an X-session, quit it, so you can test login into another console, while you are still logged in.
 
Hopefully, you have not rebooted yet! Fine. If you are in an X-session, quit it, so you can test login into another console, while you are still logged in.
  
Start Samba (including smbd, nmbd and winbindd:
+
[[Daemons|Start]] Samba (including smbd, nmbd and winbindd):
<pre>
+
 
/etc/rc.d/samba restart
+
If you check the processes, you'll see that winbind did not actually start. A quick review of the logs shows that the SID for this host could be obtained from the domain:
</pre>
+
{{hc|# tail /var/log/samba/log.winbindd|
 +
[2012/02/05 21:51:30.085574,  0] winbindd/winbindd_cache.c:3147(initialize_winbindd_cache)
 +
  initialize_winbindd_cache: clearing cache and re-creating with version number 2
 +
[2012/02/05 21:51:30.086137,  2] winbindd/winbindd_util.c:233(add_trusted_domain)
 +
  Added domain BUILTIN  S-1-5-32
 +
[2012/02/05 21:51:30.086223,  2] winbindd/winbindd_util.c:233(add_trusted_domain)
 +
  Added domain MYARCHLINUX  S-1-5-21-3777857242-3272519233-2385508432
 +
[2012/02/05 21:51:30.086254,  0] winbindd/winbindd_util.c:635(init_domain_list)
 +
  Could not fetch our SID - did we join?
 +
[2012/02/05 21:51:30.086408,  0] winbindd/winbindd.c:1105(winbindd_register_handlers)
 +
  unable to initialize domain list
 +
}}
 +
 
 +
=== Join the Domain ===
 +
 
 +
You need an AD Administrator account to do this. Let's assume this is named Administrator. The command is 'net ads join'
 +
{{hc|# net ads join -U Administrator|
 +
Administrator's password: xxx
 +
Using short domain name -- EXAMPLE
 +
Joined 'MYARCHLINUX' to realm 'EXAMPLE.COM'
 +
}}
 +
 
 +
See screenshot of Active Directory Users and Computers
 +
[[http://en.wikipedia.org/wiki/File:Ads_myarchlinux_computer_account.png]]
 +
 
 +
=== Restart Samba ===
 +
'''winbindd''' failed to start on the first try because we were not yet a domain.
 +
 
 +
[[Daemons|Restart]] the Samba service and winbind should fire up as well.
 +
 
 +
NSSwitch tells the Linux host how to retrieve information from various sources and in which order to do so. In this case, we are appending Active Directory as additional sources for Users, Groups, and Hosts.
 +
{{hc|/etc/nsswitch.conf|
 +
passwd:            files winbind
 +
shadow:            files winbind
 +
group:            files winbind
 +
 +
hosts:            files dns wins
 +
}}
  
 
=== Testing Winbind ===
 
=== Testing Winbind ===
 
Let's check if winbind is able to query the AD. The following command should return a list of AD users:
 
Let's check if winbind is able to query the AD. The following command should return a list of AD users:
  
<pre>
+
{{hc|# wbinfo -u|
wbinfo -u
+
administrator
</pre>
+
guest
 +
krbtgt
 +
test.user
 +
}}
 +
* Note we created an Active Directory user called 'test.user' on the domain controller
  
 
We can do the same for AD groups:
 
We can do the same for AD groups:
  
<pre>
+
{{hc|# wbinfo -g|
wbinfo -g
+
domain computers
</pre>
+
domain controllers
 +
schema admins
 +
enterprise admins
 +
cert publishers
 +
domain admins
 +
domain users
 +
domain guests
 +
group policy creator owners
 +
ras and ias servers
 +
allowed rodc password replication group
 +
denied rodc password replication group
 +
read-only domain controllers
 +
enterprise read-only domain controllers
 +
dnsadmins
 +
dnsupdateproxy
 +
}}
  
=== Testing login ===
+
=== Testing nsswitch ===
Now, start a new console session and try to login with an AD account. As we told winbind to use default_realms, it should not be necessary to add the AD name.
+
Lets assume there is an AD user named kain. Try to login as
+
  
<pre>
+
To ensure that our host is able to query the domain for users and groups, we test nsswitch settings by issuing the 'getent' command. The following output shows what a stock ArchLinux install looks like:
kain
+
PARADISE+kain
+
</pre>
+
  
Both should work. You should notice that /home/paradise/kain will be created.
+
{{hc|# getent passwd|
'''Log into another session using an linux account. Check that you still be able to log in as root - but keep in mind to be logged in as root in at least one session!'''
+
root:x:0:0:root:/root:/bin/bash
 +
bin:x:1:1:bin:/bin:/bin/false
 +
daemon:x:2:2:daemon:/sbin:/bin/false
 +
mail:x:8:12:mail:/var/spool/mail:/bin/false
 +
ftp:x:14:11:ftp:/srv/ftp:/bin/false
 +
http:x:33:33:http:/srv/http:/bin/false
 +
nobody:x:99:99:nobody:/:/bin/false
 +
dbus:x:81:81:System message bus:/:/bin/false
 +
ntp:x:87:87:Network Time Protocol:/var/empty:/bin/false
 +
avahi:x:84:84:avahi:/:/bin/false
 +
administrator:*:10001:10006:Administrator:/home/EXAMPLE/administrator:/bin/bash
 +
guest:*:10002:10007:Guest:/home/EXAMPLE/guest:/bin/bash
 +
krbtgt:*:10003:10006:krbtgt:/home/EXAMPLE/krbtgt:/bin/bash
 +
test.user:*:10000:10006:Test User:/home/EXAMPLE/test.user:/bin/bash
 +
}}
 +
 
 +
And for groups:
 +
{{hc|# getent group|
 +
root:x:0:root
 +
bin:x:1:root,bin,daemon
 +
daemon:x:2:root,bin,daemon
 +
sys:x:3:root,bin
 +
adm:x:4:root,daemon
 +
tty:x:5:
 +
disk:x:6:root
 +
lp:x:7:daemon
 +
mem:x:8:
 +
kmem:x:9:
 +
wheel:x:10:root
 +
ftp:x:11:
 +
mail:x:12:
 +
uucp:x:14:
 +
log:x:19:root
 +
utmp:x:20:
 +
locate:x:21:
 +
rfkill:x:24:
 +
smmsp:x:25:
 +
http:x:33:
 +
games:x:50:
 +
network:x:90:
 +
video:x:91:
 +
audio:x:92:
 +
optical:x:93:
 +
floppy:x:94:
 +
storage:x:95:
 +
scanner:x:96:
 +
power:x:98:
 +
nobody:x:99:
 +
users:x:100:
 +
dbus:x:81:
 +
ntp:x:87:
 +
avahi:x:84:
 +
domain computers:x:10008:
 +
domain controllers:x:10009:
 +
schema admins:x:10010:administrator
 +
enterprise admins:x:10011:administrator
 +
cert publishers:x:10012:
 +
domain admins:x:10013:test.user,administrator
 +
domain users:x:10006:
 +
domain guests:x:10007:
 +
group policy creator owners:x:10014:administrator
 +
ras and ias servers:x:10015:
 +
allowed rodc password replication group:x:10016:
 +
denied rodc password replication group:x:10017:krbtgt
 +
read-only domain controllers:x:10018:
 +
enterprise read-only domain controllers:x:10019:
 +
dnsadmins:x:10020:
 +
dnsupdateproxy:x:10021:
 +
}}
  
 
=== Testing Samba commands ===
 
=== Testing Samba commands ===
  
Try out some net commands to see if samba can address the AD:
+
Try out some net commands to see if Samba can communicate with  AD:
  
<pre>
+
{{hc|# net ads info|<nowiki>
net ads info
+
[2012/02/05 20:21:36.473559,  0] param/loadparm.c:7599(lp_do_parameter)
net ads lookup
+
  Ignoring unknown parameter "idmapd backend"
net ads status
+
LDAP server: 192.168.1.2
</pre>
+
LDAP server name: PDC.example.com
 +
Realm: EXAMPLE.COM
 +
Bind Path: dc=EXAMPLE,dc=COM
 +
LDAP port: 389
 +
Server time: Sun, 05 Feb 2012 20:21:33 CST
 +
KDC server: 192.168.1.2
 +
Server time offset: -3
 +
</nowiki>}}
  
The commands return several AD related information.
+
{{hc|# net ads lookup|
 +
[2012/02/05 20:22:39.298823,  0] param/loadparm.c:7599(lp_do_parameter)
 +
  Ignoring unknown parameter "idmapd backend"
 +
Information for Domain Controller: 192.168.1.2
  
== Arch Linux becomes an AD member ==
+
Response Type: LOGON_SAM_LOGON_RESPONSE_EX
 +
GUID: 2a098512-4c9f-4fe4-ac22-8f9231fabbad
 +
Flags:
 +
        Is a PDC:                                  yes
 +
        Is a GC of the forest:                      yes
 +
        Is an LDAP server:                          yes
 +
        Supports DS:                                yes
 +
        Is running a KDC:                          yes
 +
        Is running time services:                  yes
 +
        Is the closest DC:                          yes
 +
        Is writable:                                yes
 +
        Has a hardware clock:                      yes
 +
        Is a non-domain NC serviced by LDAP server: no
 +
        Is NT6 DC that has some secrets:            no
 +
        Is NT6 DC that has all secrets:            yes
 +
Forest:                example.com
 +
Domain:                example.com
 +
Domain Controller:      PDC.example.com
 +
Pre-Win2k Domain:      EXAMPLE
 +
Pre-Win2k Hostname:    PDC
 +
Server Site Name :              Office
 +
Client Site Name :              Office
 +
NT Version: 5
 +
LMNT Token: ffff
 +
LM20 Token: ffff
 +
}}
  
You need an AD Administrator account to do this. Let's assume this is named Administrator. The command is 'net ads join'
+
{{hc|<nowiki># net ads status -U administrator | less</nowiki>|<nowiki>
<pre>
+
objectClass: top
# net ads join -U Administrator
+
objectClass: person
Administrator's password: xxx
+
objectClass: organizationalPerson
Using short domain name -- PARADISE
+
objectClass: user
Joined 'MACHINE-NAME' to realm 'PARADISE.COM'
+
objectClass: computer
</pre>
+
cn: myarchlinux
 +
distinguishedName: CN=myarchlinux,CN=Computers,DC=leafscale,DC=inc
 +
instanceType: 4
 +
whenCreated: 20120206043413.0Z
 +
whenChanged: 20120206043414.0Z
 +
uSNCreated: 16556
 +
uSNChanged: 16563
 +
name: myarchlinux
 +
objectGUID: 2c24029c-8422-42b2-83b3-a255b9cb41b3
 +
userAccountControl: 69632
 +
badPwdCount: 0
 +
codePage: 0
 +
countryCode: 0
 +
badPasswordTime: 0
 +
lastLogoff: 0
 +
lastLogon: 129729780312632000
 +
localPolicyFlags: 0
 +
pwdLastSet: 129729764538848000
 +
primaryGroupID: 515
 +
objectSid: S-1-5-21-719106045-3766251393-3909931865-1105
 +
...<snip>...
 +
</nowiki>}}
 +
 
 +
== Configuring PAM ==
 +
 
 +
Now we will change various rules in PAM to allow Active Directory users to use the system for things like login and sudo access.  When changing the rules, note the order of these items and whether they are marked as '''required''' or '''sufficient''' is critical to things working as expected. You should not deviate from these rules unless you know how to write PAM rules.
 +
 
 +
In case of logins, PAM should first ask for AD accounts, and for local accounts if no matching AD account was found. Therefore, we add entries to include {{ic|pam_winbindd.so}} into the authentication process. Furthermore, we include pam_mkhomedir.so. If an AD user logs in, {{ic|/home/example/user}} will be created automatically.
 +
 
 +
{{hc|/etc/pam.d/login|<nowiki>
 +
#%PAM-1.0
 +
auth            required        pam_securetty.so
 +
auth            requisite      pam_nologin.so
 +
auth            sufficient      pam_unix.so nullok
 +
auth            required        pam_winbind.so use_first_pass use_authtok
 +
auth            required        pam_tally.so onerr=succeed file=/var/log/faillog
 +
# use this to lockout accounts for 10 minutes after 3 failed attempts
 +
#auth          required        pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog
 +
account         required        pam_access.so
 +
account        required        pam_time.so
 +
account        sufficient      pam_unix.so
 +
account        sufficient      pam_winbind.so use_first_pass use_authtok
 +
password        required        pam_pwcheck.so
 +
password        sufficient      pam_unix.so
 +
password        sufficient      pam_winbind.so use_first_pass use_authtok
 +
#password      required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
 +
#password      required        pam_unix.so sha512 shadow use_authtok
 +
session        required        pam_mkhomedir.so skel=/etc/skel/ umask=0022
 +
session        sufficient      pam_unix.so
 +
session        sufficient      pam_winbind.so use_first_pass use_authtok
 +
session        required        pam_env.so
 +
session        required        pam_motd.so
 +
session        required        pam_limits.so
 +
session        optional        pam_mail.so dir=/var/spool/mail standard
 +
session        optional        pam_lastlog.so
 +
session        optional        pam_loginuid.so
 +
-session        optional        pam_ck_connector.so nox11
 +
-session        optional        pam_systemd.so
 +
</nowiki>}}
 +
 
 +
=== Testing login ===
 +
Now, start a new console session (or ssh) and try to login using the AD credentials. The domain name is optional, as this was set in the Winbind configuration as 'default realm'. Please note that in the case of ssh, you will need to modify the {{ic|/etc/ssh/sshd_config}} file to allow kerberos authentication {{ic|(KerberosAuthentication yes)}}.
 +
 
 +
{{bc|
 +
test.user
 +
EXAMPLE+test.user
 +
}}
 +
 
 +
Both should work. You should notice that {{ic|/home/example/test.user}} will be automatically created.  Again, if you are using ssh, you need to add the pam_mkhomedir.so line mentioned above to the /etc/pam.d/sshd file.
 +
'''Log into another session using an linux account. Check that you still be able to log in as root - but keep in mind to be logged in as root in at least one session!'''
 +
 
 +
=== /etc/pam.d/gdm ===
 +
'''''TODO'''''
 +
 
 +
=== Sudo ===
 +
Another thing to get working is 'sudo'. First add the 'test.user' to /etc/sudoers. You can tweak this later, for now lets test things are working:
 +
 
 +
{{bc|/etc/sudoers|<nowiki>
 +
##
 +
## User privilege specification
 +
##
 +
root ALL=(ALL) ALL
 +
test.user ALL=(ALL) ALL
 +
</nowiki>}}
 +
 
 +
If you were to attempt a sudo now, it would fail.
 +
 
 +
Adjust the sudo file to mark {{ic|pam_unix}} as sufficient and add the line for {{ic|winbind}} as shown:
 +
 
 +
{{hc|/etc/pam.d/sudo|<nowiki>
 +
#%PAM-1.0
 +
auth            sufficient      pam_unix.so
 +
auth            required        pam_winbind.so use_first_pass use_authtok
 +
auth            required        pam_nologin.so
 +
</nowiki>}}
 +
 
 +
== Configuring Shares ==
 +
Earlier we skipped configuration of the shares. Now that things are working, go back to {{ic|/etc/smb.conf}}, and add the exports for the host that you want available on the windows network.
 +
 
 +
{{hc|/etc/smb.conf|<nowiki>
 +
[MyShare]
 +
  comment = Example Share
 +
  path = /srv/exports/myshare
 +
  read only = no
 +
  browseable = yes
 +
  valid users = @NETWORK+"Domain Admins" NETWORK+test.user
 +
</nowiki>}}
 +
 
 +
In the above example, the keyword '''NETWORK''' is to be used. Do not mistakenly substitute this with your domain name. For adding groups, prepend the '@' symbol to the group. Note that {{ic|Domain Admins}} is encapsulated in quotes so Samba correctly parses it when reading the configuration file.
 +
 
 +
 
 +
== Adding a machine keytab file and activating password-free kerberized ssh to the machine ==
 +
This explains how to generate a machine keytab file which you will need e.g. to enable password-free kerberized ssh to your machine from other machines in the domain. The scenario in mind is that you have a bunch of systems in your domain and you just added a server/workstation using the above description to your domain onto which a lot of users need to ssh in order to work - e.g. GPU workstation or an OpenMP compute node, etc. In this case you might not want to type your password every time you log in. On the other hand the key authentication used by many users in this case can not give you the necessary credentials to e.g. mount kerberized NFSv4 shares. So this will help you to enable password-free logins from your clients to the machine in question using kerberos ticket forwarding.
 +
 
 +
=== Creating a machine key tab file ===
 +
run 'net ads keytab create -U administrator' as root to create a machine keytab file in /etc/krb5.keytab. It will promt you with a warning that we need to enable keytab authentication in our configuration file, so we will do that in the next step. In my case it had problems when a key tab file is already in place - the command just did not come back it hang ... In that case you should rename the existing /etc/krb5.keytab and run the command again - it should work now.
 +
 
 +
{{bc|# net ads keytab create -U administrator}}
 +
 
 +
verify the content of your keytab by running:
 +
 
 +
{{hc|# klist -k /etc/krb5.keytab|<nowiki>
 +
Keytab name: FILE:/etc/krb5.keytab
 +
KVNO Principal
 +
---- --------------------------------------------------------------------------
 +
  4 host/myarchlinux.example.com@EXAMPLE.COM
 +
  4 host/myarchlinux.example.com@EXAMPLE.COM
 +
  4 host/myarchlinux.example.com@EXAMPLE.COM
 +
  4 host/myarchlinux.example.com@EXAMPLE.COM
 +
  4 host/myarchlinux.example.com@EXAMPLE.COM
 +
  4 host/MYARCHLINUX@EXAMPLE.COM
 +
  4 host/MYARCHLINUX@EXAMPLE.COM
 +
  4 host/MYARCHLINUX@EXAMPLE.COM
 +
  4 host/MYARCHLINUX@EXAMPLE.COM
 +
  4 host/MYARCHLINUX@EXAMPLE.COM
 +
  4 MYARCHLINUX$@EXAMPLE.COM
 +
  4 MYARCHLINUX$@EXAMPLE.COM
 +
  4 MYARCHLINUX$@EXAMPLE.COM
 +
  4 MYARCHLINUX$@EXAMPLE.COM
 +
  4 MYARCHLINUX$@EXAMPLE.COM
 +
</nowiki>}}
 +
 
 +
=== Enabeling keytab authentication ===
 +
Now you need to tell winbind to use the file by adding this line to the /etc/samba/smb.conf:
 +
 
 +
use kerberos keytab = true
 +
 
 +
It should look sth. like this:
 +
 
 +
{{hc|/etc/samba/smb.conf|<nowiki>
 +
[Global]
 +
  netbios name = MYARCHLINUX
 +
  workgroup = EXAMPLE
 +
  realm = EXAMPLE.COM
 +
  server string = %h ArchLinux Host
 +
  security = ads
 +
  encrypt passwords = yes
 +
  password server = pdc.example.com
 +
  use kerberos keytab = true
 +
  idmap uid = 10000-20000
 +
  idmap gid = 10000-20000
 +
 +
  #idmap backend = rid
 +
 
 +
  winbind use default domain = Yes
 +
  winbind enum users = Yes
 +
  winbind enum groups = Yes
 +
  winbind nested groups = Yes
 +
  winbind separator = +
 +
  winbind refresh tickets = yes
 +
  winbind gid = 10000-20000
 +
 
 +
  template shell = /bin/bash
 +
  template homedir = /home/%D/%U
 +
 
 +
  preferred master = no
 +
  dns proxy = no
 +
  wins server = pdc.example.com
 +
  wins proxy = no
 +
 
 +
  inherit acls = Yes
 +
  map acl inherit = Yes
 +
  acl group control = yes
 +
 
 +
  load printers = no
 +
  debug level = 3
 +
  use sendfile = no
 +
</nowiki>}}
 +
 
 +
Restart the winbind.service using 'systemctl restart winbind.service' with root privileges.
 +
 
 +
{{bc|# systemctl restart winbind.service}}
 +
 
 +
Check if everything works by getting a machine ticket for your system by running
 +
 
 +
{{bc|# kinit MYARCHLINUX$ -kt /etc/krb5.keytab}}
 +
 
 +
This should not give you any feedback but running 'klist' should show you sth like:
 +
 
 +
{{hc|# klist|
 +
Ticket cache: FILE:/tmp/krb5cc_0
 +
Default principal: MYARCHLINUX$@EXAMPLE.COM
 +
 +
Valid starting    Expires          Service principal
 +
02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM
 +
        renew until 02/05/12 21:27:47
 +
}}
 +
 
 +
Some common mistakes here are a) forgetting the trailing $ or b) ignoring case sensitivity - it needs to look exactly like the entry in the keytab (usually you cannot to much wrong with all capital)
 +
 
 +
 
 +
=== Preparing sshd on server ===
 +
 
 +
All we need to do is add some options to our sshd_config and restart the sshd.service.
 +
 
 +
Edit /etc/ssh/sshd_config to look like this in the appropriate places:
 +
 
 +
{{hc|# /etc/ssh/sshd_config|
 +
 
 +
...
 +
 
 +
# Change to no to disable s/key passwords
 +
ChallengeResponseAuthentication no
 +
 
 +
# Kerberos options
 +
KerberosAuthentication yes
 +
#KerberosOrLocalPasswd yes
 +
KerberosTicketCleanup yes
 +
KerberosGetAFSToken yes
 +
 
 +
# GSSAPI options
 +
GSSAPIAuthentication yes
 +
GSSAPICleanupCredentials yes
 +
 
 +
...
 +
 
 +
}}
 +
 
 +
Restart the sshd.service using:
 +
 
 +
{{bc|# systemctl restart sshd.service}}
 +
 
 +
=== Adding necessary options on client ===
 +
 
 +
First we need to make sure that the tickets on our client are forwardable. This is usually standard but we better check anyways. You have to look for the  forwardable option and set it to 'true'
 +
 
 +
{{bc|<nowiki>forwardable    =      true</nowiki>}}
 +
 
 +
Secondly we need to add the options
 +
 
 +
  GSSAPIAuthentication yes
 +
  GSSAPIDelegateCredentials yes
 +
 
 +
to our .ssh/config file to tell ssh to use this options - alternatively they can be invoked using the -o options directly in the ssh command (see 'man ssh' for help).
 +
 
 +
=== Testing the setup ===
 +
On Client:
 +
 
 +
make sure you have a valid ticket - if in doubt run 'kinit'
 +
 
 +
then use ssh to connect to you machine
 +
 
 +
{{bc|ssh myarchlinux.example.com }}
 +
 
 +
you should get connected without needing to enter your password.
 +
 
 +
if you have key authentication additionally activated then you should perform
 +
 
 +
{{bc|ssh -v myarchlinux.example.com }}
 +
 
 +
to see which authentication method it actually uses.
 +
 
 +
For debugging you can enable DEBUG3 on the server and look into the journal using journalctl
 +
 
 +
=== Nifty fine-tunig for complete password-free kerberos handling. ===
 +
 
 +
In case your clients are not using domain accounts on their local machines (for whatever reason) it can be hard to actually teach them to kinit before ssh to the workstation. Therefore I came up with a nice workaround:
 +
 
 +
== Generating user Keytabs which are accepted by AD ==
 +
 
 +
On a system let the user run:
 +
 
 +
{{bc|<nowiki>
 +
ktutil
 +
addent -password -p username@EXAMPLE.COM -k 1 -e RC4-HMAC
 +
- enter password for username -
 +
wkt username.keytab
 +
q
 +
</nowiki>}}
 +
 
 +
Now test the file by invoking:
 +
 
 +
{{bc|kinit -kt username.keytab}}
 +
 
 +
It should not promt you to give your password nor should it give any other feedback. If it worked you are basically done - just put the line above into your ~./bashrc - you can now get kerberos tickets without typing a password and with that you can connect to your workstation without typing a password while being completely kerberized and able to authenticate against NFSv4 and CIFS via tickets - pretty neat.
  
== When to reboot? ==
+
=== Nice to know ===
  
Everything checked? OK. Pray and reboot.
+
The file 'username.keytab' is not machinespecific and can therefore be copied around. E.g. we created the files on a linux machine and copied them to our Mac clients as the commands on Macs are different ...
  
= Resources =
 
  
[http://us3.samba.org/samba/ Everything there is to know about Samba]
+
== See also ==
  
Please feel free to comment this article - but if your edit this - PLEASE LET ME KNOW
+
* [http://en.wikipedia.org/wiki/Active_Directory Wikipedia: Active Directory]
 +
* [http://en.wikipedia.org/wiki/Samba_(software) Wikipedia: Samba]
 +
* [http://en.wikipedia.org/wiki/Kerberos_(protocol) Wikipedia: Kerberos]
 +
* [http://www.samba.org/samba/docs Samba: Documentation]
 +
* [http://wiki.samba.org/index.php/Samba_&_Active_Directory Samba Wiki: Samba & Active Directory]
 +
* [http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html Samba Man Page: smb.conf]
 +
=== Commercial Solutions ===
 +
* Centrify
 +
* Likewise

Revision as of 12:09, 11 June 2013

Warning: Because Arch Linux is a rolling release distribution, it is possible that some of the information in this article could be outdated due to package or configuration changes made by the maintainers. Never blindly follow these or any other instructions. When the instructions say to edit or change a file, consider making a backup copy. Check the date of the last revision of this article.

A key challenge for system administrators of any datacenter is trying to coexisting in Heterogeneous environments. By this we mean the mixing of different server operating system technologies (typically Microsoft Windows & Unix/Linux). User management and authentication is by far the most difficult of these to solve. The most common way of solving this problem is to use a Directory Server. There are a number of open-source and commercial solutions for the various flavors of *NIX; however, few solve the problem of interoperating with Windows. Active Directory (AD) is a directory service created by Microsoft for Windows domain networks. It is included in most Windows Server operating systems. Server computers on which Active Directory is running are called domain controllers.

Active Directory serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a network of Windows domain type, assigning and enforcing security policies for all computers in a network and installing or updating software on network computers. For example, when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password and specifies whether he or she is a system administrator or normal user.

Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Kerberos and DNS. These same standards are available as linux, but piecing them together is not an easy task. Following these steps will help you configure an ArchLinux host to authenticate against an AD domain.

This guide explains how to integrate an Arch Linux host with an existing Windows Active Directory domain. Before continuing, you must have an existing Active Directory domain, and have a user with the appropriate rights within the domain to: query users and add computer accounts (Domain Join).

This document is not an intended as a complete guide to Active Directory nor Samba. Refer to the resources section for additional information.

Terminology

If you are not familiar with Active Directory, there are a few keywords that are helpful to know.

  • Domain : The name used to group computers and accounts.
  • SID : Each computer that joins the domain as a member must have a unique SID or System Identifier.
  • SMB : Server Message Block.
  • NETBIOS: Network naming protocol used as an alternative to DNS. Mostly legacy, but still used in Windows Networking.
  • WINS: Windows Information Naming Service. Used for resolving Netbios names to windows hosts.
  • Winbind: Protocol for windows authentication.

Configuration

Active Directory Configuration

Warning: This section has not been validated. Proceed with caution

Updating the GPO

It may be necessary to disable Digital Sign Communication (Always) in the AD group policies. Dive into:

Local policies -> Security policies -> Microsoft Network Server -> Digital sign communication (Always) -> activate define this policy and use the disable radio button.

If you use Windows Server 2008 R2, you need to modify that in GPO for Default Domain Controller Policy -> Computer Setting -> Policies -> Windows Setting -> Security Setting -> Local Policies -> Security Option -> Microsoft network client: Digitally sign communications (always)

Linux Host Configuration

The next few steps will begin the process of configuring the Host. You will need root or sudo access to complete these steps.

Installation

Install the following packages:

Updating DNS

Active Directory is heavily dependent upon DNS. You will need to update /etc/resolv.conf to use one or more of the Active Directory domain controllers:

/etc/resolv.conf
nameserver <IP1>
nameserver <IP2>

Replacing <IP1> and <IP2> with valid IP addresses for the AD servers. If your AD domains do not permit DNS forwarding or recursion, you may need to add additional resolvers.

Note: If your machine dual boots Windows and Linux, you should use a different DNS hostname and netbios name for the linux configuration if both operating systems will be members of the same domain.

Configuring NTP

Read NTPd or OpenNTPD to configure a NTP service. Note that OpenNTPD is no longer maintained.

On the configuration, use the IP addresses for the AD servers. Alternatively, you can use other known NTP servers provided the Active directory servers sync to the same stratum. However, AD servers typically run NTP as a service.

Ensure the daemon is configured to sync automatically on startup.

Kerberos

Let's assume that your AD is named example.com. Let's further assume your AD is ruled by two domain controllers, the primary and secondary one, which are named PDC and BDC, pdc.example.com and bdc.example.com respectively. Their IP adresses will be 192.168.1.2 and 192.168.1.3 in this example. Take care to watch your syntax; upper-case is very important here.

/etc/krb5.conf
[libdefaults]
        default_realm 	= 	EXAMPLE.COM
	clockskew 	= 	300
	ticket_lifetime	=	1d
        forwardable     =       true
        proxiable       =       true
        dns_lookup_realm =      true
        dns_lookup_kdc  =       true
	
[realms]
	EXAMPLE.COM = {
		kdc 	= 	PDC.EXAMPLE.COM
                admin_server = PDC.EXAMPLE.COM
		default_domain = EXAMPLE.COM
	}
	
[domain_realm]
        .kerberos.server = EXAMPLE.COM
	.example.com = EXAMPLE.COM
	example.com = EXAMPLE.COM
	example	= EXAMPLE.COM

[appdefaults]
	pam = {
	ticket_lifetime 	= 1d
	renew_lifetime 		= 1d
	forwardable 		= true
	proxiable 		= false
	retain_after_close 	= false
	minimum_uid 		= 0
	debug 			= false
	}

[logging]
	default 		= FILE:/var/log/krb5libs.log
	kdc 			= FILE:/var/log/kdc.log
        admin_server            = FILE:/var/log/kadmind.log
Note: Heimdal 1.3.1 deprecated DES encryption which is required for AD authentication before Windows Server 2008. You'll probably have to add
allow_weak_crypto = true
to the [libdefaults] section.

Creating a Kerberos Ticket

Now you can query the AD domain controllers and request a kerberos ticket (uppercase is necessary):

kinit administrator@EXAMPLE.COM

You can use any username that has rights as a Domain Administrator.

Validating the Ticket

Run klist to verify you did receive the token. You should see something similar to:

# klist
 Ticket cache: FILE:/tmp/krb5cc_0
 Default principal: administrator@EXAMPLE.COM
 
 Valid starting    Expires           Service principal 
 02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM
         renew until 02/05/12 21:27:47

Samba

Samba is a free software re-implementation of the SMB/CIFS networking protocol. It also includes tools for Linux machines to act as Windows networking servers and clients.

Note: The configuration can vary greatly depending on how the Windows environment is deployed. Be prepared to troubleshoot and research

In this section, we will focus on getting Authentication to work first by editing the 'Global' section first. Later, we will go back and add shares.

/etc/samba/smb.conf
[Global]
  netbios name = MYARCHLINUX
  workgroup = EXAMPLE
  realm = EXAMPLE.COM
  server string = %h ArchLinux Host
  security = ads
  encrypt passwords = yes
  password server = pdc.example.com
  idmap uid = 10000-20000
  idmap gid = 10000-20000
 
  #idmap backend = rid

  winbind use default domain = Yes
  winbind enum users = Yes
  winbind enum groups = Yes
  winbind nested groups = Yes
  winbind separator = +
  winbind refresh tickets = yes
  winbind gid = 10000-20000

  template shell = /bin/bash
  template homedir = /home/%D/%U
   
  preferred master = no
  dns proxy = no
  wins server = pdc.example.com
  wins proxy = no

  inherit acls = Yes
  map acl inherit = Yes
  acl group control = yes

  load printers = no
  debug level = 3
  use sendfile = no

We shall now explain to Samba that it shall use the PDC´s database for authentication queries. Again, we use winbindd which is a part of the samba package. Winbind maps the UID and GID of the AD to our Linux-machine. Winbind uses a Unix-implementation of RPC-calls, Pluggable Authentication Modules (aka PAM) and Name Service Switch (NSS) to allow Windows AD and users accessing and to grant permissions on the Linux-machine. The best part of winbindd is, that you don´t have to define the mapping yourself, but only define a range of UID and GID. That´s what we defined in smb.conf.

Update the samba configuration file to enable the winbind daemon

/etc/conf.d/samba
 ##### /etc/conf.d/samba #####
 #SAMBA_DAEMONS=(smbd nmbd)
 SAMBA_DAEMONS=(smbd nmbd winbindd)

Next, configure samba to startup at boot. Read Daemons for more details.

Starting and testing services

Starting Samba

Hopefully, you have not rebooted yet! Fine. If you are in an X-session, quit it, so you can test login into another console, while you are still logged in.

Start Samba (including smbd, nmbd and winbindd):

If you check the processes, you'll see that winbind did not actually start. A quick review of the logs shows that the SID for this host could be obtained from the domain:

# tail /var/log/samba/log.winbindd
[2012/02/05 21:51:30.085574,  0] winbindd/winbindd_cache.c:3147(initialize_winbindd_cache)
  initialize_winbindd_cache: clearing cache and re-creating with version number 2
[2012/02/05 21:51:30.086137,  2] winbindd/winbindd_util.c:233(add_trusted_domain)
  Added domain BUILTIN  S-1-5-32
[2012/02/05 21:51:30.086223,  2] winbindd/winbindd_util.c:233(add_trusted_domain)
  Added domain MYARCHLINUX  S-1-5-21-3777857242-3272519233-2385508432
[2012/02/05 21:51:30.086254,  0] winbindd/winbindd_util.c:635(init_domain_list)
  Could not fetch our SID - did we join?
[2012/02/05 21:51:30.086408,  0] winbindd/winbindd.c:1105(winbindd_register_handlers)
  unable to initialize domain list

Join the Domain

You need an AD Administrator account to do this. Let's assume this is named Administrator. The command is 'net ads join'

# net ads join -U Administrator
Administrator's password: xxx
Using short domain name -- EXAMPLE
Joined 'MYARCHLINUX' to realm 'EXAMPLE.COM'

See screenshot of Active Directory Users and Computers [[1]]

Restart Samba

winbindd failed to start on the first try because we were not yet a domain.

Restart the Samba service and winbind should fire up as well.

NSSwitch tells the Linux host how to retrieve information from various sources and in which order to do so. In this case, we are appending Active Directory as additional sources for Users, Groups, and Hosts.

/etc/nsswitch.conf
 passwd:            files winbind
 shadow:            files winbind
 group:             files winbind 
 
 hosts:             files dns wins

Testing Winbind

Let's check if winbind is able to query the AD. The following command should return a list of AD users:

# wbinfo -u
administrator
guest
krbtgt
test.user
  • Note we created an Active Directory user called 'test.user' on the domain controller

We can do the same for AD groups:

# wbinfo -g
domain computers
domain controllers
schema admins
enterprise admins
cert publishers
domain admins
domain users
domain guests
group policy creator owners
ras and ias servers
allowed rodc password replication group
denied rodc password replication group
read-only domain controllers
enterprise read-only domain controllers
dnsadmins
dnsupdateproxy

Testing nsswitch

To ensure that our host is able to query the domain for users and groups, we test nsswitch settings by issuing the 'getent' command. The following output shows what a stock ArchLinux install looks like:

# getent passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
daemon:x:2:2:daemon:/sbin:/bin/false
mail:x:8:12:mail:/var/spool/mail:/bin/false
ftp:x:14:11:ftp:/srv/ftp:/bin/false
http:x:33:33:http:/srv/http:/bin/false
nobody:x:99:99:nobody:/:/bin/false
dbus:x:81:81:System message bus:/:/bin/false
ntp:x:87:87:Network Time Protocol:/var/empty:/bin/false
avahi:x:84:84:avahi:/:/bin/false
administrator:*:10001:10006:Administrator:/home/EXAMPLE/administrator:/bin/bash
guest:*:10002:10007:Guest:/home/EXAMPLE/guest:/bin/bash
krbtgt:*:10003:10006:krbtgt:/home/EXAMPLE/krbtgt:/bin/bash
test.user:*:10000:10006:Test User:/home/EXAMPLE/test.user:/bin/bash

And for groups:

# getent group
root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin
adm:x:4:root,daemon
tty:x:5:
disk:x:6:root
lp:x:7:daemon
mem:x:8:
kmem:x:9:
wheel:x:10:root
ftp:x:11:
mail:x:12:
uucp:x:14:
log:x:19:root
utmp:x:20:
locate:x:21:
rfkill:x:24:
smmsp:x:25:
http:x:33:
games:x:50:
network:x:90:
video:x:91:
audio:x:92:
optical:x:93:
floppy:x:94:
storage:x:95:
scanner:x:96:
power:x:98:
nobody:x:99:
users:x:100:
dbus:x:81:
ntp:x:87:
avahi:x:84:
domain computers:x:10008:
domain controllers:x:10009:
schema admins:x:10010:administrator
enterprise admins:x:10011:administrator
cert publishers:x:10012:
domain admins:x:10013:test.user,administrator
domain users:x:10006:
domain guests:x:10007:
group policy creator owners:x:10014:administrator
ras and ias servers:x:10015:
allowed rodc password replication group:x:10016:
denied rodc password replication group:x:10017:krbtgt
read-only domain controllers:x:10018:
enterprise read-only domain controllers:x:10019:
dnsadmins:x:10020:
dnsupdateproxy:x:10021:

Testing Samba commands

Try out some net commands to see if Samba can communicate with AD:

# net ads info
[2012/02/05 20:21:36.473559,  0] param/loadparm.c:7599(lp_do_parameter)
  Ignoring unknown parameter "idmapd backend"
LDAP server: 192.168.1.2
LDAP server name: PDC.example.com
Realm: EXAMPLE.COM
Bind Path: dc=EXAMPLE,dc=COM
LDAP port: 389
Server time: Sun, 05 Feb 2012 20:21:33 CST
KDC server: 192.168.1.2
Server time offset: -3
# net ads lookup
[2012/02/05 20:22:39.298823,  0] param/loadparm.c:7599(lp_do_parameter)
  Ignoring unknown parameter "idmapd backend"
Information for Domain Controller: 192.168.1.2

Response Type: LOGON_SAM_LOGON_RESPONSE_EX
GUID: 2a098512-4c9f-4fe4-ac22-8f9231fabbad
Flags:
        Is a PDC:                                   yes
        Is a GC of the forest:                      yes
        Is an LDAP server:                          yes
        Supports DS:                                yes
        Is running a KDC:                           yes
        Is running time services:                   yes
        Is the closest DC:                          yes
        Is writable:                                yes
        Has a hardware clock:                       yes
        Is a non-domain NC serviced by LDAP server: no
        Is NT6 DC that has some secrets:            no
        Is NT6 DC that has all secrets:             yes
Forest:                 example.com
Domain:                 example.com
Domain Controller:      PDC.example.com
Pre-Win2k Domain:       EXAMPLE
Pre-Win2k Hostname:     PDC
Server Site Name :              Office
Client Site Name :              Office
NT Version: 5
LMNT Token: ffff
LM20 Token: ffff
# net ads status -U administrator | less
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
cn: myarchlinux
distinguishedName: CN=myarchlinux,CN=Computers,DC=leafscale,DC=inc
instanceType: 4
whenCreated: 20120206043413.0Z
whenChanged: 20120206043414.0Z
uSNCreated: 16556
uSNChanged: 16563
name: myarchlinux
objectGUID: 2c24029c-8422-42b2-83b3-a255b9cb41b3
userAccountControl: 69632
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 129729780312632000
localPolicyFlags: 0
pwdLastSet: 129729764538848000
primaryGroupID: 515
objectSid: S-1-5-21-719106045-3766251393-3909931865-1105
...<snip>...

Configuring PAM

Now we will change various rules in PAM to allow Active Directory users to use the system for things like login and sudo access. When changing the rules, note the order of these items and whether they are marked as required or sufficient is critical to things working as expected. You should not deviate from these rules unless you know how to write PAM rules.

In case of logins, PAM should first ask for AD accounts, and for local accounts if no matching AD account was found. Therefore, we add entries to include pam_winbindd.so into the authentication process. Furthermore, we include pam_mkhomedir.so. If an AD user logs in, /home/example/user will be created automatically.

/etc/pam.d/login
#%PAM-1.0
auth            required        pam_securetty.so
auth            requisite       pam_nologin.so
auth            sufficient      pam_unix.so nullok
auth            required        pam_winbind.so use_first_pass use_authtok
auth            required        pam_tally.so onerr=succeed file=/var/log/faillog
# use this to lockout accounts for 10 minutes after 3 failed attempts
#auth           required        pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog
account         required        pam_access.so
account         required        pam_time.so
account         sufficient      pam_unix.so
account         sufficient      pam_winbind.so use_first_pass use_authtok
password        required        pam_pwcheck.so
password        sufficient      pam_unix.so
password        sufficient      pam_winbind.so use_first_pass use_authtok
#password       required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
#password       required        pam_unix.so sha512 shadow use_authtok
session         required        pam_mkhomedir.so skel=/etc/skel/ umask=0022
session         sufficient      pam_unix.so
session         sufficient      pam_winbind.so use_first_pass use_authtok
session         required        pam_env.so
session         required        pam_motd.so
session         required        pam_limits.so
session         optional        pam_mail.so dir=/var/spool/mail standard
session         optional        pam_lastlog.so
session         optional        pam_loginuid.so
-session        optional        pam_ck_connector.so nox11
-session        optional        pam_systemd.so

Testing login

Now, start a new console session (or ssh) and try to login using the AD credentials. The domain name is optional, as this was set in the Winbind configuration as 'default realm'. Please note that in the case of ssh, you will need to modify the /etc/ssh/sshd_config file to allow kerberos authentication (KerberosAuthentication yes).

test.user
EXAMPLE+test.user

Both should work. You should notice that /home/example/test.user will be automatically created. Again, if you are using ssh, you need to add the pam_mkhomedir.so line mentioned above to the /etc/pam.d/sshd file. Log into another session using an linux account. Check that you still be able to log in as root - but keep in mind to be logged in as root in at least one session!

/etc/pam.d/gdm

TODO

Sudo

Another thing to get working is 'sudo'. First add the 'test.user' to /etc/sudoers. You can tweak this later, for now lets test things are working:

/etc/sudoers

If you were to attempt a sudo now, it would fail.

Adjust the sudo file to mark pam_unix as sufficient and add the line for winbind as shown:

/etc/pam.d/sudo
#%PAM-1.0
auth            sufficient      pam_unix.so
auth            required        pam_winbind.so use_first_pass use_authtok
auth            required        pam_nologin.so

Configuring Shares

Earlier we skipped configuration of the shares. Now that things are working, go back to /etc/smb.conf, and add the exports for the host that you want available on the windows network.

/etc/smb.conf
[MyShare]
  comment = Example Share
  path = /srv/exports/myshare
  read only = no
  browseable = yes
  valid users = @NETWORK+"Domain Admins" NETWORK+test.user

In the above example, the keyword NETWORK is to be used. Do not mistakenly substitute this with your domain name. For adding groups, prepend the '@' symbol to the group. Note that Domain Admins is encapsulated in quotes so Samba correctly parses it when reading the configuration file.


Adding a machine keytab file and activating password-free kerberized ssh to the machine

This explains how to generate a machine keytab file which you will need e.g. to enable password-free kerberized ssh to your machine from other machines in the domain. The scenario in mind is that you have a bunch of systems in your domain and you just added a server/workstation using the above description to your domain onto which a lot of users need to ssh in order to work - e.g. GPU workstation or an OpenMP compute node, etc. In this case you might not want to type your password every time you log in. On the other hand the key authentication used by many users in this case can not give you the necessary credentials to e.g. mount kerberized NFSv4 shares. So this will help you to enable password-free logins from your clients to the machine in question using kerberos ticket forwarding.

Creating a machine key tab file

run 'net ads keytab create -U administrator' as root to create a machine keytab file in /etc/krb5.keytab. It will promt you with a warning that we need to enable keytab authentication in our configuration file, so we will do that in the next step. In my case it had problems when a key tab file is already in place - the command just did not come back it hang ... In that case you should rename the existing /etc/krb5.keytab and run the command again - it should work now.

# net ads keytab create -U administrator

verify the content of your keytab by running:

# klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   4 host/myarchlinux.example.com@EXAMPLE.COM
   4 host/myarchlinux.example.com@EXAMPLE.COM
   4 host/myarchlinux.example.com@EXAMPLE.COM
   4 host/myarchlinux.example.com@EXAMPLE.COM
   4 host/myarchlinux.example.com@EXAMPLE.COM
   4 host/MYARCHLINUX@EXAMPLE.COM
   4 host/MYARCHLINUX@EXAMPLE.COM
   4 host/MYARCHLINUX@EXAMPLE.COM
   4 host/MYARCHLINUX@EXAMPLE.COM
   4 host/MYARCHLINUX@EXAMPLE.COM
   4 MYARCHLINUX$@EXAMPLE.COM
   4 MYARCHLINUX$@EXAMPLE.COM
   4 MYARCHLINUX$@EXAMPLE.COM
   4 MYARCHLINUX$@EXAMPLE.COM
   4 MYARCHLINUX$@EXAMPLE.COM

Enabeling keytab authentication

Now you need to tell winbind to use the file by adding this line to the /etc/samba/smb.conf:

use kerberos keytab = true

It should look sth. like this:

/etc/samba/smb.conf
[Global]
  netbios name = MYARCHLINUX
  workgroup = EXAMPLE
  realm = EXAMPLE.COM
  server string = %h ArchLinux Host
  security = ads
  encrypt passwords = yes
  password server = pdc.example.com
  use kerberos keytab = true
  idmap uid = 10000-20000
  idmap gid = 10000-20000
 
  #idmap backend = rid

  winbind use default domain = Yes
  winbind enum users = Yes
  winbind enum groups = Yes
  winbind nested groups = Yes
  winbind separator = +
  winbind refresh tickets = yes
  winbind gid = 10000-20000

  template shell = /bin/bash
  template homedir = /home/%D/%U
   
  preferred master = no
  dns proxy = no
  wins server = pdc.example.com
  wins proxy = no

  inherit acls = Yes
  map acl inherit = Yes
  acl group control = yes

  load printers = no
  debug level = 3
  use sendfile = no

Restart the winbind.service using 'systemctl restart winbind.service' with root privileges.

# systemctl restart winbind.service

Check if everything works by getting a machine ticket for your system by running

# kinit MYARCHLINUX$ -kt /etc/krb5.keytab

This should not give you any feedback but running 'klist' should show you sth like:

# klist
 Ticket cache: FILE:/tmp/krb5cc_0
 Default principal: MYARCHLINUX$@EXAMPLE.COM
 
 Valid starting    Expires           Service principal 
 02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM
         renew until 02/05/12 21:27:47

Some common mistakes here are a) forgetting the trailing $ or b) ignoring case sensitivity - it needs to look exactly like the entry in the keytab (usually you cannot to much wrong with all capital)


Preparing sshd on server

All we need to do is add some options to our sshd_config and restart the sshd.service.

Edit /etc/ssh/sshd_config to look like this in the appropriate places:

# /etc/ssh/sshd_config

...

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
KerberosAuthentication yes
#KerberosOrLocalPasswd yes
KerberosTicketCleanup yes
KerberosGetAFSToken yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

...

Restart the sshd.service using:

# systemctl restart sshd.service

Adding necessary options on client

First we need to make sure that the tickets on our client are forwardable. This is usually standard but we better check anyways. You have to look for the forwardable option and set it to 'true'

forwardable     =       true

Secondly we need to add the options

 GSSAPIAuthentication yes
 GSSAPIDelegateCredentials yes

to our .ssh/config file to tell ssh to use this options - alternatively they can be invoked using the -o options directly in the ssh command (see 'man ssh' for help).

Testing the setup

On Client:

make sure you have a valid ticket - if in doubt run 'kinit'

then use ssh to connect to you machine

ssh myarchlinux.example.com 

you should get connected without needing to enter your password.

if you have key authentication additionally activated then you should perform

ssh -v myarchlinux.example.com 

to see which authentication method it actually uses.

For debugging you can enable DEBUG3 on the server and look into the journal using journalctl

Nifty fine-tunig for complete password-free kerberos handling.

In case your clients are not using domain accounts on their local machines (for whatever reason) it can be hard to actually teach them to kinit before ssh to the workstation. Therefore I came up with a nice workaround:

Generating user Keytabs which are accepted by AD

On a system let the user run:

ktutil
addent -password -p username@EXAMPLE.COM -k 1 -e RC4-HMAC
- enter password for username -
wkt username.keytab
q

Now test the file by invoking:

kinit -kt username.keytab

It should not promt you to give your password nor should it give any other feedback. If it worked you are basically done - just put the line above into your ~./bashrc - you can now get kerberos tickets without typing a password and with that you can connect to your workstation without typing a password while being completely kerberized and able to authenticate against NFSv4 and CIFS via tickets - pretty neat.

Nice to know

The file 'username.keytab' is not machinespecific and can therefore be copied around. E.g. we created the files on a linux machine and copied them to our Mac clients as the commands on Macs are different ...


See also

Commercial Solutions

  • Centrify
  • Likewise