Linux Mint 17.1 LTS (MATE) AD integration
Step 1: Install and update Linux Mint and required applications
I won't go into too much detail here, installation instructions can be found on the Linux Mint website. 
Install Linux Mint 17.1 LTS with the Mate desktop environment. Install 64bit version if you have 4GB or more RAM. Install required applications. 
Uninstall any applications you don’t want (torrent, chat etc) 
Install all updates that are waiting.
Step 2: Change the login window
Menu > Preferences > Login window 
- Select a GDM login window, avoiding the userlist ones, Arc-Wise or Linux Mint would be a good choice 
- Under “options” uncheck “Automatically select last logged in user”
Step 3: Create a new account to be used as a template for all users
Create a new user account with appropriate user rights. This will be the master account from which your network user profiles will be created. I named my user account “template”. Its a good idea to use the same password that you use for your admin account, as this account essentially is for admin purposes.

Login to the new account, and set it up how you want the domain user accounts to be - theme, wallpaper, icons and icon layout, start menu items. If you have any visual tweaks (e.g clearer fonts) configure those too.

Add network printers if you have them

Logout then log back in with your sudo account

Step 4: Configurng the Windows AD domain logon
Download the latest version of Power Broker Identity Services Open Edition (PBIS open) from here:

Now we need to install ssh-server which is required by PBIS open's installer. 
Open a terminal window and type (enter your password when prompted: 
sudo apt-get update 
sudo apt-get install openssh-server

Still in terminal window, navigate to the directory where pbis-open-[version_number] is located (usually by typing "cd Downloads"), execute the following command (replacing [version number]): 
sudo chmod +x pbis-open-[version_number]

From the terminal window type the following command to install PBIS open (replacing [version number]): 
sudo ./pbis-open-[version_number]

When asked “Install packages for legacy links?” answer “No”. 
When asked “Install now?” answer “yes”. 
A "join domain" dialogue window should open.

In the window, type the credentials to join the domain. Domain should be FQDN e.g MYDOMAIN.lan (keep the domain name uppercase). The second domain box will autocomplete. Don’t change it!. Enter the login credential of an account with AD rights to join the domain. Join the domain. 
You should see a SUCCESS message. Recently whilst joining a domain I received a DNS error, in this case I changed MYDOMAIN.lan to MYDOMAIN.LAN rather than .lan, after which I could join. This maybe due to a version difference in PBIS between this time and last time. 
If you see the warning “some services require a manual restart sshd”, open a new terminal window and type: 
sudo service ssh restart

Reboot, and login again with local admin account (not domain account)

Step 5: Give superuser rights (sudo) to domain admins
Open terminal, and type: 
sudo visudo -f /etc/sudoers 
Scroll down to the part that says: “#Members of the admin group may gain root privileges” and there add the following "as-is": 
Hit Ctrl+X, then hit Y to save changes

Step 6: Important! Test the domain account logon
Before you start mapping drives, test the domain login. 
First reboot, then login with a domain account. This is an important step, as incorrectly defined mappings can actually affect your ability to logon, and we'll be in a mess if we don't even know if logins WERE working before we started defining mappings or not. If it’s not working, don’t move to the next step. Fix it first.

Step 7: Mapping user share
The created user share is mounted on the desktop and is also visible in Nemo file manager. 
Users cannot unmount the share mappings themselves unless they are domain admins.

Log in with the local sudo account

From terminal, install the libpam-mount package: 
sudo apt-get install libpam-mount

Now lets edit the config. This time we’ll use pluma so its easier to follow the xml markup. In terminal. type: 
sudo pluma /etc/security/pam_mount.conf.xml

First we’ll map the user share: 
After the line that says: “<!-- Volume definitions →>” add the following:

<volume user="*" 

In the above example, replace YOURSERVER with the hostname of the server, (don’t use the FQDN). e.g enter server1, not server1.yourdomain.local. 
path= here you need enter the path to the users’ share. Typically this would be "Users/%(DOMAIN_USER)" - the %(DOMAIN_USER) is a preset variable which grabs the username. Don’t change this. 
mountpoint= you can customise this to whatever you want, but I’ve inserted U: and the username, as this is what the user is used to seeing in Windows. Keep the ~/ in front

Step 8: Mapping other drives
If there are other server shares, lets map those. The method is similar, except you also need to specify the domain group (sgrp) to which the mapping applies. If the user doesn’t belong to the group, the mapping will be skipped. Add the required share right below the user share you added in the previous step.

<volume sgrp= “DOMAIN\groupname” 

Replace “DOMAIN” with the name of your domain in uppercase. don’t use the FQDN - i.e use MYDOMAIN not MYDOMAIN.local 
Replace “groupname” with the name of your AD group. I’m pretty sure this is case-sensitive, so be careful to enter the group name exactly as it appears in AD. 
Replace “YOURSERVER” with the hostname of your server (exactly as in previous step) 
Replace path “Sharename” with the name of the server share, again lets play safe and assume its case-sensitive. 
Mountpoint can be whatever you like but keep the ~/ in front

Test the share by logging on with a domain account that has access to that share. Do this for each of the mappings you want to add. Test each one after you add it, by logging out then logging in with a domain account. Make sure that you use a test account that has access to all the shares that you’re mapping.

If you're unable to login after creating a new mapping, something is wrong with the last mapping you created. Go back and check it carefully from your sudo account. I have found that sometimes a reboot is needed to make subsequent (after a failed login) changes to pam_mount.conf.xml actually stick. I ended up rebooting after each attempt to fix, and it paid off.

Step 9: Apply the user profile template
Now we’ll apply the master user profile (see step 3) to all future domain account logons.

sudo nano /etc/pam.d/common-session

At the beginning of the last section of this file, add the following line (Replace “pathtotemplateprofile” with the path to your profile. In my example this would read skel=/home/template/):

session required skel=/pathtomasterprofile/ umask=0022

NOTE: If you add this line to the very end (as I had previously instructed), the command loads too late, and the skel profile doesn't get created

Find and delete the domain profile you used previously from /home/

Logout, then login with your test domain account. You should now see the desktop configured just as you configured the template account.

Step 10: Make a domain account act as a guest account
Guest accounts are not supported in MDM currently, but I figured out (with the help of the interweb) how to emulate guest account behaviour. It goes like this: At logoff, check for the existence of the [ACCOUNTNAME] folder in /home/local/[DOMAIN]/[ACCOUNTNAME] (where [DOMAIN] is the name of your domain, and [ACCOUNTNAME] is the username of the guest account (DOMAIN should be in uppercase). The script below will run when any user logs out. 
In case the computer isn’t shut down properly, you could also add the same code to a startup script /etc/mdm/PostLogin/Default

Decide which domain account you want to use as a guest account. Create one on the AD server if you don’t already have one suitable.

Create a script named in /usr/local/bin 
sudo nano /usr/local/bin/

add this code to it replacing “[DOMAIN]” and “[ACCOUNTNAME]” with those applicable to your domain: 
if test -d /home/local/[DOMAIN]/[ACCOUNTNAME] 
rm -rf /home/local/[DOMAIN]/[ACCOUNTNAME] 
Hit Ctrl+X to exit, then hit Y to save

Now lets make the script executable: 
sudo chmod 511 /usr/local/bin/

Now lets add some code to the MDM logout script: 
sudo nano /etc/mdm/PostSession/Default

just before the last line (exit 0) add the following code: 

Step 11: Test
Delete all previously logged in domain accounts from /home/local/YOURDOMAIN/


Login with your domain guest account as defined in Step 10.

Create some files and folders on the desktop


Log back in again, and they should be gone.

Step 12: Put your feet up
A lot of the guides I have see for joining Linux Ubuntu variants to a domain are either out of date, or are not 100% compatible with Linux Mint 17.1 LTS. This how-to really pulls together working parts from several guides, and with some extra pieces of my own added, and with the hope that someone other than me will find it a useful guide.

Since Mint 17.1 is a Long Term Support version, and that Linux Mint is currently the most popular Linux distro out there, it seems right that it should have a comprehensive AD integration guide.


smb://;This email address is being protected from spambots. You need JavaScript enabled to view it. /---/