This guide explains how to integrate an ArchLinux host with an existing Windows Active Directory domain.

+

{{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.}}

−

== Disclaimer ==

+

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.

−

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 ==

+

[[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.

−

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.

+

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 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 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).

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.

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

−

=== AD Basic Terminology ===

+

== Terminology ==

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

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

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

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

−

=== Arch Linux Packages ===

+

=== Installation ===

−

The following packages should also be installed:

+

[[Pacman|Install]] the following packages:

−

* samba

+

* {{Pkg|samba}}

−

* krb-5

+

* {{Pkg|pam-krb5}} ---- error: does not exist in latest version or arch linux!

−

* pam-krb5

+

* {{Pkg|pam_pwcheck}}

−

* pam_pwcheck

+

* {{Pkg|openntpd}} (or) {{Pkg|ntp}}

−

* openntpd (or) ntp

−

−

pacman -S samba pam-krb5 pam_pwcheck openntpd

=== Updating DNS ===

=== 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:

+

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:

−

nameserver <IP1>

+

{{hc|/etc/resolv.conf|

−

nameserver <IP2>

+

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.

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.

−

'''''Important:''''' 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.

+

{{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 ===

=== Configuring NTP ===

−

In this example, we use OpenNTPD instead of ISC NTP. You may choose either package, but openntpd is cleaner and easier to configure.

+

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

−

−

==== /etc/conf.d/openntpd ====

−

Ensure the daemon is configured to 'sync' automatically on startup by adding the '-s' paramater to the config:

−

PARAMS="-s"

−

−

==== /etc/ntpd.conf ====

−

servers <IP1>

−

servers <IP2>

−

Replacing <IP1> and <IP2> with valid 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/rc.conf ====

+

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.

−

Next, add 'openntpd' to the list of startup daemons in the ArchLinux configuration file:

−

DAEMONS=(!hwclock syslog-ng dbus network openntpd crond sshd)

−

* Note we place it AFTER 'network' and BEFORE 'crond'

−

==== Start openntpd ====

+

Ensure the daemon is configured to '''sync automatically on startup'''.

−

Start the NTP daemon to sync the time now.

−

rc.d start openntpd

=== Kerberos ===

=== Kerberos ===

−

<p> 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.</p>

+

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.

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

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

−

kinit administrator@EXAMPLE.COM

+

{{bc|kinit administrator@EXAMPLE.COM}}

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

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

==== Validating the Ticket ====

==== Validating the Ticket ====

−

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

+

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

−

# klist

+

{{hc|# klist|

Ticket cache: FILE:/tmp/krb5cc_0

Ticket cache: FILE:/tmp/krb5cc_0

Default principal: administrator@EXAMPLE.COM

Default principal: administrator@EXAMPLE.COM

Line 149:

Line 125:

02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM

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

renew until 02/05/12 21:27:47

−

+

}}

=== Samba ===

=== 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.

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.

−

==== /etc/samba/smb.conf ====

+

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

−

'''''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.

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.

−

<pre>

+

{{hc|/etc/samba/smb.conf|<nowiki>

[Global]

[Global]

netbios name = MYARCHLINUX

netbios name = MYARCHLINUX

Line 167:

Line 142:

encrypt passwords = yes

encrypt passwords = yes

password server = pdc.example.com

password server = pdc.example.com

−

idmapd uid = 10000-20000

+

idmap uid = 10000-20000

−

idmapd gid = 10000-20000

+

idmap gid = 10000-20000

−

#idmapd backend = rid

+

#idmap backend = rid

winbind use default domain = Yes

winbind use default domain = Yes

Line 195:

Line 170:

debug level = 3

debug level = 3

use sendfile = no

use sendfile = no

−

</pre>

+

</nowiki>}}

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.

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

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

−

<pre>

+

{{hc|# net ads join -U Administrator|

−

# net ads join -U Administrator

Administrator's password: xxx

Administrator's password: xxx

Using short domain name -- EXAMPLE

Using short domain name -- EXAMPLE

Joined 'MYARCHLINUX' to realm 'EXAMPLE.COM'

Joined 'MYARCHLINUX' to realm 'EXAMPLE.COM'

−

</pre>

+

}}

See screenshot of Active Directory Users and Computers

See screenshot of Active Directory Users and Computers

Line 252:

Line 219:

=== Restart Samba ===

=== 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:

+

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

−

rc.d restart samba

−

+

[[Daemons|Restart]] the samba service and winbind should fire up as well.

−

=== /etc/nsswitch.conf ===

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.

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

passwd: files winbind

shadow: files winbind

shadow: files winbind

Line 265:

Line 230:

hosts: files dns wins

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

administrator

guest

guest

krbtgt

krbtgt

test.user

test.user

−

</pre>

+

}}

* Note we created an Active Directory user called 'test.user' on the domain controller

* 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

domain computers

domain controllers

domain controllers

Line 301:

Line 261:

dnsadmins

dnsadmins

dnsupdateproxy

dnsupdateproxy

−

</pre>

+

}}

=== Testing nsswitch ===

=== Testing nsswitch ===

Line 307:

Line 267:

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:

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:

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.

+

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.

−

=== /etc/pam.d/login ===

+

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.

−

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.

−

<pre>

+

{{hc|/etc/pam.d/login|<nowiki>

#%PAM-1.0

#%PAM-1.0

auth required pam_securetty.so

auth required pam_securetty.so

Line 497:

Line 451:

-session optional pam_ck_connector.so nox11

-session optional pam_ck_connector.so nox11

-session optional pam_systemd.so

-session optional pam_systemd.so

−

</pre>

+

</nowiki>}}

=== Testing login ===

=== 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'.

+

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)}}.

−

<pre>

+

{{bc|

test.user

test.user

EXAMPLE+test.user

EXAMPLE+test.user

−

</pre>

+

}}

−

Both should work. You should notice that /home/example/test.user will be automatically created.

+

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!'''

'''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!'''

Line 515:

Line 469:

=== Sudo ===

=== 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:

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 ====

+

−

<pre>

+

{{bc|/etc/sudoers|<nowiki>

##

##

## User privilege specification

## User privilege specification

Line 522:

Line 476:

root ALL=(ALL) ALL

root ALL=(ALL) ALL

test.user ALL=(ALL) ALL

test.user ALL=(ALL) ALL

−

</pre>

+

</nowiki>}}

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

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

−

==== /etc/pam.d/sudo ====

+

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

−

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

−

<pre>

+

{{hc|/etc/pam.d/sudo|<nowiki>

#%PAM-1.0

#%PAM-1.0

auth sufficient pam_unix.so

auth sufficient pam_unix.so

auth required pam_winbind.so use_first_pass use_authtok

auth required pam_winbind.so use_first_pass use_authtok

auth required pam_nologin.so

auth required pam_nologin.so

−

</pre>

+

</nowiki>}}

== Configuring Shares ==

== 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.

+

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.

−

<pre>

+

{{hc|/etc/smb.conf|<nowiki>

[MyShare]

[MyShare]

comment = Example Share

comment = Example Share

Line 546:

Line 499:

browseable = yes

browseable = yes

valid users = @NETWORK+"Domain Admins" NETWORK+test.user

valid users = @NETWORK+"Domain Admins" NETWORK+test.user

−

</pre>

+

</nowiki>}}

−

In the above example, the keywork '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.

+

In the above example, the keywork '''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.

Revision as of 20:50, 8 March 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.

Installation

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.

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.

Restart Samba

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.

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:

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.

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:

In the above example, the keywork 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.