Thursday, 30 July 2009

Samba, Squid and Active Directory authentication

This post is the end of a few weeks of challenging debugging.

At $WORK we are implementing a new proxy server based on Squid. Unlike our old proxy, we want to authenticate each user against Active Directory. In order for this to work, Samba (or more specifically, the Winbind component of Samba) needs to be configured.

Getting Samba setup

Consider that Windows networking in the Active Directory world is built on DNS for name resolution, Kerberos for authentication, LDAP for directory services and the SMB protocol for file, print and RPC.

The first step was to configure the proxy server to use the AD Domain Controllers for DNS resolution. This was done by editing /etc/resolv.conf and configuring /etc/nsswitch.conf.

The second step was to get Kerberos working. I've detailed this in another blog posting. This also needs to point to the AD Domain Controllers for the KDC.

Configuring Samba was also fairly straightforward. There was no need to run smbd (used for file and print serving) or nmbd (the naming service) as this box would not be performing those roles. The winbindd server needs to be running. This is responsible for authenticating against the Active Directory.

The smb.conf can be small:

workgroup = CSS
server string = Squid Proxy and Samba Server
security = ADS
log file = /var/log/samba/%m.log
max log size = 50
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
dns proxy = No
hosts allow = 10.1, 127.

To join the domain, run the net ads join command, using the credentials of a domain administrator. You should be able to confirm whether the trust worked by typing:

# wbinfo -t
checking the trust secret via RPC calls succeeded

If that's okay, try pulling in a list of users, again using wbinfo but this time using the -u flag:

# wbinfo -u

And this is where things started to go wrong for me. Sometimes it would work, but most of the time it would error. This took a lot of investigating and the details can be found here in the Samba mailing list archive. It was this bit that took the time to debug.

Getting Squid working

Having got wbinfo to now return the list of users, it was time to configure Squid to use ntlm_auth (which in turn uses winbindd to perform the authentication request). The /etc/squid/squid.conf needs the following:

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5

At this point everything should work wonderfully...

Except Squid was unable to authenticate, complaining about the permissions on /var/lib/samba/winbindd_privileged. It appears that Winbind expects this directory to have 750 permissions with root:root ownership, while Squid runs as the "squid" user. According to one post I read about the issue, it may be caused by the way that Red Hat have built Squid. One possible workaround is to use an ACL (yes really, a use for ACLs in Unix!) but it appears my install doesn't have ACL support enabled(!).

So the immediate workaround for me is to create a script that basically does the following:

  • Set permissions on /var/lib/samba/winbindd_privileged to 750
  • Start Winbind
  • Set permissions on /var/lib/samba/winbindd_privileged to 777 (yes, I know...)
  • Start Squid

This appears to work okay until I can find a real solution.

So although this is now working, it's taken longer than anticipated. The thing about Samba, and Active Directory integration is that it's so complicated with so many options. The learning curve is steep, but I'm starting to feel I now have a grip on it.


Mac said...

Here in my work place we have win2k3 ADS ( we are using samba as file server (
my problem is that i have to create two users in both the machines ADS & samba. & have to ask user to keep same pw in both.
Can u please explain me more that how can i deploy single authentication system.


JR said...

Hi Manish

If I'm reading your question correctly, you've got Samba users setup on your file server (using smbpasswd).

You need to look at taking the Samba server and joining your Active Directory domain. When you do this, all users and passwords will be authenticated against the AD (using winbind) and not your local server.

Hope this helps