MFA with Google Authenticator

 Set server up so user can log in with an ssh key or Google authenticator (won't need both). 

If a user doesn't have key access setup they'll have to use Google Authenticator, they won't be able to log in with a password

The user still needs to type the password to log into cockpit

/etc/ssh/sshd_config

ChallengeResponseAuthentication yes

# Uncomment this to force google authenticator AND a public key

#AuthenticationMethods publickey,keyboard-interactive

/etc/pam.d/cockpit

# google authenticator for two-factor

auth  required  pam_google_authenticator.so secret=/home/${USER}/.ssh/.google_authenticator

/etc/pam.d/sshd

#Commented out to not allow passwords

#auth       substack     password-auth

# Use Google authenticator for login

auth       required     pam_google_authenticator.so nullok secret=/home/${USER}/.ssh/.google_authenticator

To setup a user with Google Authenticator make sure to use the -s option

 google-authenticator -s /home/test/.ssh/.google_authenticator

Using winbind to authenticate to an active directory - Part 3

Having successfully set up my AD domain and got RHEL 6 clients authenticating to it, I'll now describe how to do the same thing for RHEL 5 clients.

You can read about the AD setup in Part 1 and the RHEL 6 configuration in Part 2.

I have performed a customized RHEL 5 installation, removing Desktop Environments, Applications, Printer Servers and reset the run level to 3.

yum install samba3x-winbind (you don't need samba for authentication)

Run authconfig-tui --enablemkhomedir to configure winbind, set the following options:
user information: use winbind
authentication: winbind
winbind domain: MY
security model: ads
winbind ads realm: MY.DOM
winbind domain controllers: dc.my.dom
template shell: /bin/bash

Don't click join domain at this stage.
When the wizard completes it will attempt to start winbind and fail. We haven't finished configuring yet so this is fine.
Remove the existing configuration databases, rm -f /var/lib/samba/*

Modify /etc/samba/smb.conf with the following options. This will map all AD users & groups into the range 100000-199999.

workgroup = MY
password server = dc1.my.dom
realm =MY.DOM
security = ads
idmap config * : backend = tdb
idmap config * : range = 200000-299999
idmap config my:backend  = rid
idmap config my:range    = 100000 - 199999
idmap config my:base_rid = 0
idmap uid = 100000-299999
idmap gid = 100000-299999

You can also set these useful options:

template shell = /bin/bash
winbind use default domain = true
winbind enum users = yes  (let's you use getent passwd to see AD users)
winbind enum groups = yes  (let's you use getent group to see AD groups)
winbind offline logon = true  (cached users can log in when AD is unavailable. Very useful)

Now rerun authconfig-tui --enablemkhomedir and click join domain. Supply the AD domain password when prompted and the client will join the domain successfully. You will be able to see the client in the Windows ADUC tool

It should now start up properly:
chkconfig winbind on ; service winbind start


I'm not setting up centralised home directories so we'll use oddjobd to automatically create home directories when an AD user logs on for the first time to a client.

We'll set the home directories up in /home/MY and make them private. RHEL 6 uses oddjobd for this. RHEL 5 doesn't.

mkdir /home/MY
chmod 711 /home/MY 
Modify /etc/pam.d/system-auth-ac to fix home dir permissions 
    session     optional      pam_mkhomedir.so umask=0077

Now restrict ssh access to users in the grp-linux-servers AD group.

Edit /etc/security/pam_winbind.conf
    require_membership_of = grp-linux-servers

Finally restrict root access via sudo to those in the grp-root-access AD group

Edit /etc/sudoers
%grp-root-access        ALL=(ALL)       NOPASSWD: ALL

Some useful commands to check things are working:

wbinfo -u / wbinfo -g will pull a user and group list from the AD
wbinfo -D my / wbinfo --dc-info=my will put details of AD and associated DCs
getent passwd / getent group will show the client's passwd & group list including AD entries.

In Part 4 I'll describe how to achieve this on a Solaris 10 client. This is the most complex to set up as there is no out the box integration and it also requires additional freeware packages.

Using winbind to authenticate to an active directory - Part 2

Here I'll describe how to configure a RHEL 6 installation to authenticate using winbind to the AD my.dom set up in Part 1. RHEL 6 is the easiest client to configure as it has samba and winbind integration built into the OS.

I'll assume a basic server installation has been performed. You may need to add additional packages if you've gone with a minimal install.

yum install winbind (you don't need samba for authentication)

Run system-config-authentication or authconfig-tui to configure winbind, set the following options:

user account database: winbind
winbind domain: MY
security model: ads
winbind ads domain: MY.DOM
winbind domain controllers: dc.my.dom
template shell: /bin/bash
Advanced option: create home directories on first logon

Don't click join domain at this stage.
When the wizard completes it will attempt to start winbind and fail. We haven't finished configuring yet so this is fine.
Remove the existing configuration databases, rm -f /var/lib/samba/*

The key thing when integrating into a domain is to make sure the Unix UID / GID are consistent across all unix hosts. Winbind provides several mapping strategies for doing this. I'm using idmap_rid as it's simple to setup, doesn't require an external database and performs an algorithmic mapping from Windows SIDs to UID / GIDs

Modify /etc/samba/smb.conf with the following options. This will map all AD users & groups into the range 100000-199999.

workgroup = MY
password server = dc1.my.dom
realm =MY.DOM
security = ads
idmap config * : backend = tdb
idmap config * : range = 200000-299999
idmap config my:backend  = rid
idmap config my:range    = 100000 - 199999
idmap config my:base_rid = 0
idmap uid = 100000-299999
idmap gid = 100000-299999

You can also set these useful options:

template shell = /bin/bash
winbind use default domain = true
winbind enum users = yes  (let's you use getent passwd to see AD users)
winbind enum groups = yes  (let's you use getent group to see AD groups)
winbind offline logon = true  (cached users can log in when AD is unavailable. Very useful)

Now rerun the authentication gui / tui and click join domain. Supply the AD domain password when prompted and the client will join the domain successfully. You will be able to see the client in the Windows ADUC tool

It should now start up properly:
chkconfig winbind on ; service winbind start

I'm not setting up centralised home directories so we'll use oddjobd to automatically create home directories when an AD user logs on for the first time to a client.

We'll set the home directories up in /home/MY and make them private:

mkdir /home/MY
chmod 711 /home/MY
Edit /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf
Change 2 umasks to -u 0077 (from 0002) to make home dirs private
service oddjobd restart

Now restrict ssh access to users in the grp-linux-servers AD group.

Edit /etc/security/pam_winbind.conf
    require_membership_of = grp-linux-servers

Finally restrict root access via sudo to those in the grp-root-access AD group

Edit /etc/sudoers
%grp-root-access        ALL=(ALL)       NOPASSWD: ALL

Some useful commands to check things are working:

wbinfo -u / wbinfo -g will pull a user and group list from the AD
wbinfo -D my / wbinfo --dc-info=my will put details of AD and associated DCs
getent passwd / getent group will show the client's passwd & group list including AD entries.

In Part 3 I'll describe how to do the same thing for a RHEL 5 client. The principals are the same but RHEL 5 isn't so tightly integrated with windbind out the box so we have to do a little bit of extra work.

The joys of SSH tunnels

We all now how to use a simple SSH tunnel to be able to remote desktop to a machine hidden behind a firewall.

For example create a tunnel to server1 to be able to RDP onto server2. In this example we'll use port 6000 so make sure nothing is running on that port on server1 first:

• Use putty to ssh onto server1
• Within putty create a local tunnel with a source port of 6000 and a destination port of server2:3389
• Now point your rdp client to localhost:6000 and your connection to server2 magically opens

Now let's extend that to 2 tunnels. In this example we can't directly reach server2 that can reach our windows box called server3. We'll create a tunnel to server1, then another tunnel from server1 to server2 and finally server2 will create the connection to server3. Again we'll use port 6000 so check it's not being used on either server1 or server2.

• Use putty to ssh onto server1
• Within putty create a local tunnel with a source port of 6000 and a destination port of localhost:6000
• Now connect to server2 from server1 like this:

ssh -L 6000:server3:3389 server2

• Once your ssh session opens fire up remote desktop and point to localhost:6000 and your connection to server3 appears before your eyes.

SSH tunnels are truely wonderful.