Ubuntu: auto mount DFS shares on login

This tutorial shows you how to automatically mount users' home directories on login in Ubuntu when the shares to mount are in a DFS namespace.

Before you proceed, make sure you have joined the Ubuntu workstation to Windows domain and configured WINS client by following this tutorial. DFS uses WINS by default so you need WINS feature installed in some server.

First you need to install the following packages:

sudo apt-get install libpam-mount cifs-utils keyutils

In /etc/security/pam_mount.conf.xml add a volume tag for each share you want to mount for users automatically:

<volume user="*" sgrp="residents" fstype="cifs" server="your.domain.com" 
    path="data/users/%(USER)/documents" mountpoint="~/Documents"
    options="uid=%(USER),gid=100,dir_mode=0700">
</volume>

The parameters above are:

• user: Limit the volume for specific users only. Wildcard (*) mounts the volume for all users, if no other filters are applied.
• sgrp: Limit the volume to users which are a member of the group identified by name. In my domain environment, all regular users are in a group called residents.
• fstype: The filesystem type. Use cifs here to mount NTFS shares.
• server and path: Here goes the full DFS path. If users' documents are in \\your.domain.com\Data\Users\%username%\Documents, put \\your.domain.com in server and data/users/%(USER)/documents in path. See the manpage link below to find a list of other variables.
• mountpoint: This is where the share is mounted.
• options: Here you can define some extra options. For example dir_more sets the permissions of mountpoint.

You can find more information about the config file in the manpage.

Edit or add the following line in /etc/pam.d/common-session:

session optional pam_mount.so

Edit or add tge following line in /etc/pam.d/common-auth:

auth optional pam_mount.so

Now when users log in, their documents have been automatically mounted in ~/Documents.

Join Ubuntu 14 to Active Directory

This summer I worked at my university, where I got a great change to get familiar with Linux. Naturally this got me thinking Could I deploy Ubuntu at home as well? This is how you join Ubuntu workstations to Active Directory and let users logon with their AD credentials.

First, let's install necessary packages (do not insert the line break):

apt-get install winbind samba libnss-winbind
  libpam-winbind krb5-config krb5-locales krb5-user

Windows 2000 and later uses Kerberos as its default authentication method. Kerberos is a computer network authentication protocol which works on the basis of 'tickets' to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. (source: Wikipedia). Now open /etc/krb5.conf in your favorite text editor (for example sudo nano /etc/krb5.conf) to configure Kerberos settings. Append to [libdefaults] section:

       default_realm = YOUR.DOMAIN.COM
       ticket_lifetime = 24000
       default_tgs_enctypes = rc4-hmac des-cbc-md5
       default_tkt_enctypes = rc4-hmac des-cbc-md5
       permitted_enctypes = rc4-hmac des-cbc-md5
       dns_lookup_realm = true
       dns_lookup_kdc = true
       dns_fallback = yes

Append to [realms] section:

        YOUR.DOMAIN.COM = {
                kdc = your.domain.com:88
                default_domain = your.domain.com
        }

Append to [domain_realm] section:

        .your.domain.com = YOUR.DOMAIN.COM
        your.domain.com = YOUR.DOMAIN.COM

Append the following sections:

[appdefaults]

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

[logging]

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

Try to get a ticket from AD administrator:

kinit Administrator@YOUR.DOMAIN.COM

Enter the admin password when prompted. Next, edit /etc/samba/smb.conf:

netbios name = COMPUTER_HOSTNAME
workgroup = YOUR
security = ADS
realm = YOUR.DOMAIN.COM
encrypt passwords = yes
idmap config *:backend = rid
idmap config *:range = 5000-100000
winbind allow trusted domains = no
winbind trusted domains only = no
winbind use default domain = yes
winbind enum users  = yes
winbind enum groups = yes
winbind refresh tickets = yes
client ntlmv2 auth = yes

template shell = /bin/bash

wins server = WINS_SERVER_IP
name resolve order = lmhosts host wins bcast

I have a DFS that uses WINS, so I add WINS server address here. You can omit that if you don't need WINS. Remove the default workgroup that you just replaced from the file.
Edit the following files in /etc/nsswitch.conf:

passwd:         compat winbind
group:          compat winbind
hosts:          files wins mdns4_minimal [NOTFOUND=return] dns

Join the computer in domain:

net ads join -k

service winbind restart
service nmbd restart
service smbd restart

pam-auth-update

If you want that home directories are automatically created for new users, add the following file in the end of /etc/pam.d/common-account:

session required pam_mkhomedir.so skel=/etc/skel umask=0077

This gives users full access to their homes, but no access to anyone else. You also need to allow manual login for users to be able to login with their AD credentials. Add the following line in /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf:

greeter-show-manual-login=true

Now restart Ubuntu and try to login with any AD account.

Authenticate WiFi users with Active Directory

In this tutorial we are going to install a Network Policy Server which enables us to authenticate Wi-Fi users with Active Directory. We will configure a Wi-Fi AP to point to the NPS Server which allows users to log in to a wireless network with their AD credentials.

This is an old tutorial of mine, so unfortunately I don't have screenshots. The server software to use is Windows Server 2008 R2. If you already have installed Active Directory Certificate Services on your domain, skip to Create certificate for NPS.

Install AD CA

Open Server Manager, expand Roles and click Add Roles. Choose Active Directory Certificate Services. Here is an example configuration, but you can modify it to fulfill your needs. The first-level bullets represent the configuration windows you're going to see:

• Select Role Services:
• Choose Certificate Authority and Certificate Authority Web Enrollment.
• Specify Setup Type:
• Certificate Authority is going to be installed on a domain controller, so choose Enterprise.
• Specify CA Type:
• Choose Root CA. The other option is for those who want the CA certificate to be obtained from a 3rd party CA.
• Set Up Private Key:
• Choose Create a new private key.
• Configure Cryptography for CA:
• Continue with default settings, which are
• Cryptography service provider: RSA
• Key character length: 2048
• Hash algorithm: SHA1
• Leave the Allow administrator interaction when the private key is accessed by the CA checkbox unticked.
• Configure CA Name:
• Continue with default settings.
• Set Validity Period:
• This is how long your CA certificate is going to be valid. I chose 5 years.
• Configure Certificate Database:
• Continue with defaults (C:\Windows\System32\CertLog)

Now make sure your public key policies in default domain policy are correct. Open Group Policy Management and edit Default Domain Policy. Expand Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies and set:

• Certificate Services Client - Auto-Enrollment:
• Enable policy
• Tick Renew expired certificated, update pending certificates, and remove revoked certificates.
• Tick Update certificates that use certificate templates.
• Certificate Path Validation Settings > Stores tab:
• Tick Define these policy settings.

Create certificate for NPS

Open Microsoft Management Console (open command prompt, type in mmc and hit enter). Add the following snap-ins (File > Add/Remove Snap-ins):

1. Certificate Authority (Local)
2. Certificate Templates
3. Certificates (Computer account)

Expand Certificate Templates and right click RAS and IAS Server and click Duplicate Template. In Duplicate Template window, choose Windows Server 2008 Enterprise.

A Properties of New Template window will pop up. In General tab, type RAS and IAS Server Template for NPS in Template display name. Tick Publish certificate in Active Directory. In Security tab, select RAS and IAS Servers from the list and tick allow for Enroll and Autoenroll. Click OK.

Expand Certificate Authority (Local), right click Certificate Templates and click New > Certificate Template to Issue. Select RAS and IAS Server Template for NPS and click OK.

Expand Certificates (Local Computer) > Personal > Certificates and find the newly created certificate according to the Certificate Template column. Right click it and go to properties. Type NPS as a friendly name.

Install NPS Role

Open Server Manager, expand Roles and click Add Roles. Choose Network Policy and Access Services. In Select Role Services window, choose Network Policy Server.

Open Network Policy and Access Services Management and on the left pane choose NPS (Local). In Standard configuration choose RADIUS server for 802.1X Wireless or Wired Connections and click Configure 802.1X link.

• Select 802.1X Connection Type:
• Choose Secure Wireless Connections and give Secure Wireless Connections as the name.
• Specify 802.1X Switches:
• Here we will add your wireless access point by clicking on Add. Enter a friendly name (e.g. wlan-livingroom) and the IP Address of the AP (e.g. 192.168.0.50).
• Tick Manual secret and create a unique secret. You will need to provide this secret to your access point.
• Configure an Authentication Method:
• Choose Microsoft: Protected EAP (PEAP). Click Configure and select the NPS certificate that we just created in Certificate issued. Make sure that the Friendly name reads NPS.
• Specify User Groups:
• Click Add and add the group of users and/or computers that are allowed to log in to Wi-Fi networks.

Configure access points

This is something you probably have to figure out by yourself. I have a couple of ZyXEL NWA1121-NI access points, where the right configuration is as follows:

• Security mode: WPA2
• Primary RADIUS server: enabled
• Primary server IP address: IP of your NPS server
• Primary server port: 1812
• Primary share secret: this is the secret you created earlier

Now you should be able to log in to the Wi-Fi with your AD credentials. Note that many devices (including Windows and Apple) need to trust the root certificate in order to join the Wi-Fi. I use Cisco Meraki to deploy the CA certificate to Apple mobile devices. If your computer is not domain-joined, you need to manually import the CA certificate to Trusted Root Certification Authorities.

Active Directory authentication with PHP

I'm running an intra site with contents that require users to log in. Many tutorials and code snippets I've found online work only if you have set your LDAP server signing requirements group policy to None. Mine is set to Require signing as by default in Server 2008 R2. It took me surprisingly long to get this rather short and simple piece of code to work, so I thought to share it with you. This function returns true if username and password are correct (for any AD user), else false. Tested on IIS 7.5.

function login_ldap($username, $password) {
    $ldap = ldap_connect("ldap://example.local");
    if ($ldap === false) return false;
    // set the LDAP protocol
    ldap_set_option($ldap, LDAP_OPT_PROTOCOL_VERSION, 3);
    ldap_set_option($ldap, LDAP_OPT_REFERRALS, 0);
    putenv('LDAPTLS_REQCERT=never');
    // start SSL
    ldap_start_tls($ldap);
    // ldap_bind will return true if user authenticated, else false
    $bind = @ldap_bind($ldap, "EXAMPLE\\" . $username, $password);
    ldap_close($ldap);
    return $bind;
}

WSUS with SSL and remote WSUSContents

In this post I'm going to introduce how to install WSUS on a Hyper-V virtual machine, configure SSL between the server and clients and store WSUSContents folder outside the VM.

Windows Server Update Services (WSUS) is a Windows software that allows administrators to control the delivery of Windows updates in domain environments. WSUS is available as a role in Windows Server 2003 SP2 and later. Windows workstations can be configured to point to WSUS server and download updates from there instead of Windows Update directly. By default, WSUS doesn't utilize SSL between the server and client workstations.

According to some sources, Microsoft recommends and supports storing the downloaded updates only on the same server with WSUS. The WSUSContent folder, however, can be configured on a remote server, too. The reason why I do this is that I want a full backup of the WSUS virtual machine, but at the same time I don't want the ever-changing and relatively large WSUSContent folder to be backed up and waste space on my virtual machine.

This how-to assumes that you have set up a Windows domain environment with DNS and Certificate authority. In this tutorial, the Hyper-V has already been installed on a physical server called SRV-3. It has one virtual machine, SRV-3A, which has Windows Server 2012 installed. Both servers are domain-joined. We are going to set up WSUS on SRV-3A and configure it to store the update files on SRV-3. Some existing knowledge of WSUS is going to be helpful.

Prepare SRV-3 to store update files

For me the SRV-3 Hyper-V server also functions as a backed-up DFS file server. I don't want the Windows update files to waste any space on the backup disk, so I'm going to configure a separate volume for non-backed up shares. If space is no problem and you want to store Windows updates on the virtual machine instead, you can skip this part and jump to Install WSUS and other components.

1. On SRV-3, navigate to Start menu > Administrative Tools > Computer Management.
2. Expand Storage > Disk Management.
3. Right-click C volume (C:) and choose Shrink Volume.
4. Windows update files may take a lot of space, so enter 50000 MB (50 GB) as the amount of space to shrink.
5. Format the volume as NTFS and assign it a drive letter (I chose N:).

Disk Management on SRV-3 after the non-backup volume has been formatted.

After the volume has been formatted, create folder Shared folders to the root of the non-backup volume. Go to Properties > Security and click Advanced. Click Change Permissions and uncheck Include inheritable permissions from this object's parent. Remove the current permissions and give SYSTEM and Administrators full access to the folder.

Now let's create a shared folder for Windows update files. Go to N:\Shared folders and create folder WSUS. BITS (Background Intelligent Transfer Service) works under NETWORK SERVICE and WSUS uses its computer account to access the update files folder. Therefore right-click Shared folders and go to Properties > Security and in addition to the inherited permissions, give Users read permissions, and SRV-3A and NETWORK SERVICE full access permissions. Then on the Sharing tab, click Advanced Sharing. Enter WSUSStorage as the share name. Click Permissions and give Everyone full access.

A summary of what happened on SRV-3 in last paragraph:

Path:	NTFS Permissions:	Sharing settings:
N:\Shared folders	Administrators: Full access SYSTEM: Full access	Not shared
N:\Shared folders\WSUS	Inherited permissions, and NETWORK SERVICE: Full access iis-user: Read * SRV-3A: Full access Users: Read	\\SRV-3\WSUSStorage Everyone: Full control

* this will be configured later

Now the windows update files can be stored outside the virtual machine, namely in \\SRV-3\WSUSStorage. Remember to exclude the created volume from backup if your aims are the same as mine.

Install WSUS and other components

On SRV-3A, open Server Manager. Click Add roles and features and choose Windows Server Update Services. If prompted for required role services, review this and proceed. When the installation Wizard asks you for the update location (Store updates in the following location), enter \\SRV-3\WSUSStorage. If you skipped the previous section and want to store update files on the virtual machine, you can also enter a desired local path. Other than that, you can proceed with the installation wizard by using the default settings.

After the installation has succeeded, click Lauch post-installation tasks. This will start the actual WSUS installation wizard. It is pretty self-explanatory, and asks questions about desired languages, products and classifications. I chose Finnish and English (because my Windows servers are in English and workstations in Finnish), all classifications except drivers, and the default product categories.

The default configuration installs the WSUS database locally on Windows Internal Database. By default the database may use as much memory as available, which will eventually make your server run out of RAM. There are also other methods to change this setting, such as via command prompt, but my method is to install SQL Server Management Studio and change the configuration via GUI. Modifying the database for WSUS 4 (on Server 2012) requires SQL Server 2012 Management Studio (download here and choose ENU\x64\SQLManagementStudio_x64_ENU.exe). If your WSUS server runs on Server 2008 R2 you have installed WSUS 3, and you'll need SQL Server 2005 Management Studio which you'll find here. Install the software with default settings.

After installation open SQL Server Management Studio and connect to

• \\.\pipe\Microsoft##WID\tsql\query (Server 2012), or
• \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query (Server 2008 R2).

Right click the pipe and choose Properties. On the Memory tab set Maximum server memory to 1024 MB (or other depending on your specs).

Setting maximum memory usage in SQL Server Management Studio.

TIP: If you cannot install SQL Management Studio because your computer doesn't have .NET 2.0, you can install it in Server Manager > Add features > .NET Framework 3.5 Features.

I also suggest you to install Microsoft Report Viewer which is available here.

Configure IIS

As I mentioned, storing Windows update files on a different server than WSUS is not a supported configuration. Therefore you must do this little tweak to get things work correctly. On SRV-3A, open IIS Manager and expand Sites > WSUS Administration > Content and click Basic Settings on the right pane. Change physical path to \\SRV-3\WSUSStorage\WsusContent\.

I have a separate user account for IIS in Active Directory (iis-user) which I use to connect IIS to file system. I suggest you to create iis-user account in Active Directory Users and Computers and grant it read permissions to WSUSStorage share on SRV-3. Then, on SRV-3A Basic settings window, click Connect as and enter the username and password of iis-user. If you click Test settings you should see two green check marks to indicate that IIS can connect to the folder where Windows update files are stored.

Basic settings of Content directory in IIS Manager.

Next we'll configure SSL. Open IIS and navigate to SRV-3A > Server Certificates. Click Create Domain Certificate and fill in the appropriate details. If your domain name is example.local, I suggest you to choose wsus.example.local as common name and later create a corresponding CNAME using the DNS Manager (Administrative Tools > DNS).

Expand Sites > WSUS Administration and click Bindings. Choose https and click Edit. Choose the newly-created SSL certificate and close the window. Then expand the WSUS Administration site and for each of ApiRemoting30, ClientWebService, DSSAuthWebService, ServerSyncWebService and SimpleAuthWebService, choose SSL Settings and check Require SSL. For the rest of the virtual directories, do not configure require SSL. After this open an elevated command prompt and:

cd "c:\Program Files\Update Services\Tools"

WSUSUtil.exe configuressl wsus.example.local

This will return a string containing the address for client computers (for example https://wsus.example.local:8531).

Now, open Group policy editor, edit a GPO and do the following configurations for desired workstations and servers in Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update:

• Configure automatic updates: enable
• Specify intranet Microsoft update server location: enable and https://wsus.example.local:8531 to both fields

This would be a good moment to restart SRV-3A.

Finished :)

Now you can open the WSUS console on SRV-3A and start approving updates. Be patient with client computers, as it may take a little while until they first report to WSUS.

About this blog

Hi and welcome! I'm a second year IT student at Aalto University in Finland. I've been into Windows products and technologies for years and I've been maintaining a Windows domain environment at home for several years. This blog has been on my to-do list for a long time, mainly because of me being worried about kicking off with a proper start, including the very basics of setting up an AD environment and such. In the end I decided it's better to get going with just something, rather than leaving this wait for the inspiration for the perfect first post.

In this blog I'm going to concentrate on configurations and technical solutions in Windows domain environment, but also on other tech-related stuff. Or maybe something else as well, who knows?

Welcome again to the blog!

Here is also a secret message for my Finnish fellas:

Aluksi tarkoitukseni oli luoda kokonaan suomenkielinen blogi, mutta lopulta päädyin kirjoittamaan englanniksi. Onhan tämä IT-kieli niin englantipainoitteista, että loppu menee lontooksi samaan syssyyn :) Tervetuloa blogiin!