Midgard CMS: NTLM single sign-on (original) (raw)

  1. Prerequisites
  2. Changes in Midgard compilation
  3. Samba installation
  4. Configuring Winbindd
    1. Setting up smb.conf file
    2. Joining workstation to domain
    3. Configure /etc/krb5.conf
    4. Test krb5 configuration
    5. Join ADS
    6. Testing that winbindd daemon works
  5. Configuring Midgard with NTLMSSP.
  6. Configuring browser to use NTLM
  7. PAM authentication with LDAP

NTLM single sign-on is a deprecated third party authentication mechanism in Midgard. It allows single sign-on with Windows networks. In single sign-on users who are logged into a Windows network get recognized automatically by Midgard.

Since July 2006, Kerberos single sign-on is the recommended mechanism instead.

NTLM support is deprecated, and is not supported in Apache 2

Prerequisites

In order to get NTLMSSP support in Midgard working you'll need:

Changes in Midgard compilation

  1. Compile and install midgard-apache1. In addition to a general configure options for midgard-apache1, add --with-ntlm-auth. Your Apache must support EAPI (available from www.modssl.org), this is the case when you install modssl support. Most Linux vendors do this by default in their Apache packages as EAPI requires patching of main Apache core.

Samba installation

The easiest way to install Samba 3.0 is to use binary packages provided by your distribution or from Samba Team's site: http://samba.org/samba/ftp/Binary_Packages/ .

After installing the package above do the following:

Add system group `winbind':   
# groupadd -r winbind

Change access permissions to winbindd's privileged pipe to that group:   
# make -p /var/cache/samba/winbindd_privileged   
# chmod 750 /var/cache/samba/winbindd_privileged   
# chown root:winbind /var/cache/samba/winbindd_privileged

the winbindd_privileged pipe directory can be in different place on different distributions. For example, on older Red Hat systems it is in /var/cache/samba/winbindd_privilaged (notice the typo), and on Debian in /var/run/samba/winbindd_privileged. Tune the commands accordingly.

Add server under which Apache process is functioning into `winbind' group:   
# usermod -G winbind apache

Configuring Winbindd

After installing Samba we need to configure Winbind service. For getting NTLMSSP support in Midgard we don't need actually to run smbd and nmbd daemons, all needed functionality is provided by winbindd daemon.

To do that we need:

Setting up smb.conf file

Following settings are of importance for winbind:

for NT4-like domains:

workgroup =    
security = domain   
password server =

for Active Directory sevices:

workgroup =    
security = ads   
realm =    
encrypt passwords = yes

Optionally you might set up 'password server' if Samba is unavailable to get your ADS server from realm:

password server =

common options for winbindd in smb.conf:

idmap uid = 10000-20000  # range of UIDs used by winbindd for   
                         # Windows users. Should not overlap with  
                     # any other NSS module  
idmap gid = 10000-20000  # same for GIDs   

winbind separator = +   

winbind use default domain = false

winbind use default domain must be true for PAM authentication to work, and false for NTLM, making them incompatible with each other.

Joining workstation to domain

There is a `net' utility in Samba 3.0 for management purposes. It covers under one umbrella several different management tasks. One of them is domain management.

To join a NT4-like domain:

# net join -U Administrator%password -S your.pdc.server

where Administrator is an account with administrative privileges in domain and password is its password.

In case of success you'll get following message:

Joined domain

To join an Active Directory services you need to do a bit more work:

Configure /etc/krb5.conf

The minimal configuration is following:

[realms]   
    YOUR.KERBEROS.REALM = {   
            kdc = your.kerberos.server   
    }

Test krb5 configuration

To test it try following krb5's utility:

# kinit USERNAME@REALM

and make sure there was no error during its run (Win2000 should accept your password if there was no error).

The realm must be uppercase or you'll get Cannot find KDC for requested realm while getting initial credentials.

Also, time between two servers should be in sync. Otherwise you would get kinit(v5): Clock skew too great while getting initial credentials.

One of important moments in Active Directory setup is to ensure that you can successfully do reverse DNS lookup on the IP address on both your KDC and the workstation. Also, the name that this lookup maps to must either be the NetBIOS name of the KDC (i.e. the hostname without domain attached) or it can alternatively be the NetBIOS name followed by realm.

Join ADS

Once steps above are done, join workstation to ADS:

# net join -U Administrator%password

Testing that winbindd daemon works

After all preparatory work, we need to test configuration. To do it, first run winbind under root with interactive mode:

# /usr/sbin/winbindd -i

in other console run `wbinfo' utility:

# wbinfo -a user%password

where user' is some domain user andpassword' is his/her password. There should be no error messages. If there are no errors, stop winbindd using ^C and run it in daemon mode.

Configuring Midgard with NTLMSSP.

All configuration is done in mod_midgard. We have following options:

Syntax:  MidgardAuthNTLM    
Example: MidgardAuthNTLM "/usr/bin/ntlm_auth"

Enables authentication of users with NTLMSSP over HTTP. It allows seamless login in into corporate Intranet sites with user's password in CIFS domain. The only parameter for this option is path to Samba 3.0's ntlm_auth utility. Please note that the user Apache is running under should have access to Winbind's priviledged pipe and, of course, Winbind itself should be properly configured before using this option.

Syntax:  MidgardNTLMDomainMap     
Example: MidgardNTLMDomainMap "FOO" "BAR"

Maps domain of user from CIFS networks to specific sitegroup in Midgard. Can be specified multiple times for different domains. This option is virtual server-wide and the whole map between domains and sitegroups is empty by default for every virtual host.

Simple Midgard w/ NTLMSSP confguration looks like:

MidgardAuthNTLM "/usr/bin/ntlm_auth"   
MidgardNTLMDomainMap "MyDomain" "MySitegroup"

Note: In some domains the may be simply the hostname of the Active Directory server, i.e. AD instead of AD.EXAMPLE.NET.

Start Midgard Framework and try to connect to any auth-protected host in the virtual server you've configured for use with NTLMSSP. If you are trying to access that host from Windows NT4/2000/XP machine with aid of Internet Explorer 4.5+ or Mozilla 1.4, then you should be logged in without any pop-up dialogs appearing at client side.

Configuring browser to use NTLM

NTLM single sign-on requires support from the browser. Internet Explorer supports NTLM by default for sites in the "Local Intranet" zone. To add your Midgard site into this zone either access it via hostname only ("intra" instead of "intra.mycompany.com") and add the appropriate MidgardHost entry for this, or add your site to the zone manually. NTLM authentication can also be enabled manually in the security settings by enabling "Automatic login".

PAM authentication with LDAP

Make sure you have PAM_LDAP installed. Add to your virtual host:

MidgardAuthType PAM
MidgardPamFile midgard

MidgardPamFile is optional (default is 'midgard')

Create file /etc/pam.d/midgard:

auth required /lib/security/pam_ldap.so config=/etc/ldap_midgard.conf

Create /etc/ldap_midgard.conf

uri ldaps://ldap.example.com
base dc=example,dc=com
scope sub
ssl yes
TLS_CACERT /etc/openldap/cacert.pem

Make sure you have the users you want to use in Midgard database and dont leave empty passwords because midgard fallbacks to basic auth.