Integrating Squid and Samba3 with NTLM authentication

Posted by mkeadle

ABOUT

In our current setup, Squid is handling proxy services for a small army of Windows 2000 and XP clients. When doing any sort of log analysis, our basic setup only allowed us to track access by IP address or FQDN. While this has proven to be enough in most cases, it would still be nice to connect traffic to a specific person. Squid has the ability to require users to authenticate before gaining access to it’s services, but another place to login would not make staff, faculty, or students very happy. This is a perfect chance to take advantage of NTLM authentication.

NTLM authentication is a means to send a users login credentials through their web browser. It’s most popular use is in Outlook Web Access (OWA). If you have signed onto a computer in the same domain as the Exchange server , and your email account is the same as your domain account, you most likely will be able to access OWA without having to supply your username and password. This happens because Internet Explorer passes your domain information once requested by OWA. Using Samba, we can give Squid the ability to request that same information from each users web browser, preventing the need to manually enter any information and allowing us to track traffic by userid.

REQUIRED PACKAGES

Before you begin, make sure you have all the pieces you need. If you’re in Gentoo this is easily done by issueing:

  # USE="ldap kerberos" emerge squid samba -v

Squid
For the purposes of this writeup I’ll assume you allready have Squid up and running. It will need some reconfiguring, but we’ll leave it alone for the moment.

Kerberos/Heimdal
You’ll need kerberos or heimdal for Samba to be able to communicate with Active Directory. In Red Hat, the packages you’ll need are:

  • krb5-libs, krb5-devel, krb5-workstation, krb5-server, pam_krb5

If you’re using SUSE you’ll instead need:

  • heimdal-lib, heimdal-devel, heimdal, pam_krb5

Using the previously mention command for Gentoo will take care of all needed dependancies.

Samba
This process is possible with earlier versions, but this document will be dealing with Samba3. The Samba authors recommend using at least version 3.0.2.

UPDATE: There have been changes to Samba in Gentoo since this document was put together. When I’ve got time I’ll make the adjestments here, but for now read about them in this thread on the Gentoo forums. Thanks to jsleeper for the update.

KERBEROS CONFIGURATION

Kerberos is easy to configure and just as easy to test. Once installed you only need to create or edit it’s main configure file located at /etc/krb5.conf .

Listing 1. Kerberos configuration file: /etc/krb5.conf
[libdefaults]
    default_realm = RICHMOND.RICH.EDU

[realms]
    RICHMOND.RICH.EDU = {
    kdc = inns-fs1.richmond.rich.edu
    }

It is important to note that the kerberos configuration file is case sensitive, and your realm must be in UPPERCASE. There are no background processes to start once kerberos is configured, so you can move straight into testing that it is working with the kinit utility.

Listing 2. Kerberos testing with kinit
root#  kinit [username]@RICHMOND.RICH.EDU
Password for [username]@RICHMOND.RICH.EDU:

Make sure your password is accepted, where [username] is a valid domain account name. The command should complete without any errors. You can confirm the process was successful with the following.

Listing 3. Kerberos confirming with kinit
root#  klist -e

Your kerberos tickets that are cached by the system will be displayed.

SAMBA CONFIGURATION

If you’ve ever configured Samba before, this won’t be that difficult. The only real challenge is getting Samba to join the Active Directory domain. Similar to kerberos, we only need to edit Samba’s main config file, usually located at /etc/samba/smb.conf .

Listing 4. Samba configuration file: /etc/samba/smb.conf
[global]
        workgroup = RICHMOND
        netbios name = SQUID
        realm = RICHMOND.RICH.EDU
        server string = Linux Samba Server
        security = ads
        encrypt passwords = Yes
        password server = dc1, dc2
        log file = /var/log/samba/%m.log
        max log size = 0
        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
        preferred master = False
        local master = No
        domain master = False
        dns proxy = No
        wins server = 10.100.0.1
        winbind separator = /
        winbind enum users = yes
        winbind enum groups = yes
        winbind use default domain = yes
        idmap uid = 10000-20000
        idmap gid = 10000-20000

You’ll need to enter your correct workgroup, netbios name, realm, password servers (domain controllers), and WINS server. Once this file is created it’s time to join up with Active Directory. Before Samba3, a computer account needed to be manually created before joining the domain, but now we’re able to do that directly from the command line.

Listing 5. Joing an Active Directory domain with Samba3
root#  net ads join -U [username]%richmond

In the above example, [username] is the name of a domain account allowed to create domain machine accounts. Depending on your Active Directory setup, it may or may not ask you for a password. In either case you should see that the join was successful. Now that the machine is a member of the domain we can start the needed Samba services. Different distributions start services in different ways, so make sure you’re using the correct way for your server.

Listing 6. Starting the Samba services
root#  /etc/init.d/samba start
root#  /etc/init.d/winbind start

Remember to add the Samba services to the correct runlevel so they will be started at every boot. Red Hat users can use the chkconfig command. In Gentoo I do this with rc-update. The next step is to check that your connection to the domain is good and your able to view information from Active Directory. A few tests with wbinfo will do the trick.

Listing 7. Checking the machine trust account
root#  wbinfo -t
checking the trust secret via RPC calls succeeded

Listing 8. Enumerating domain users with wbinfo
root#  wbinfo -u
RICHMOND+Administrator
RICHMOND+Guest
RICHMOND+mkeadle
...

Listing 9. Enumerating domain groups with wbinfo
root#  wbinfo -g
RICHMOND+Domain Computers
RICHMOND+Domain Controllers
RICHMOND+Schema Admins
RICHMOND+Enterprise Admins
RICHMOND+Domain Admins
...

The final test is with the utility that will eventually handle the actual user authentication for Squid.

Listing 10. Testing with ntlm_auth
root#  /usr/bin/ntlm_auth --username=[username]
password: XXXXXXXX

A successful run of the above command will yield: NT_STATUS_OK: Success (0x0). If you are not successful, double check your configs and try again. If you can’t get this step to work then you certainly won’t have any greater success with Squid.

NSS CONFIGURATION

NSS stand for Name Service Switch and controls how user accounts are attempted to be authenticated. Since you need accounts to be tested against the domain, you need to tell NSS to use that as a source of authentication. Edit the bellow lines in your /etc/nsswitch.conf file to contain the following.

Listing 11. NSS configuration file: /etc/nsswitch.conf
passwd:  files  winbind
shadow:  files
group:  files  winbind

SQUID CONFIGURATION

The first step in preparing Squid is making sure you have a dedicated user and group for Squid to run as. By default, Squid runs under the nobody account, but you’ll need something more specific to help later contain some permissions. Traditionally, the user and group used for this are squid:squid. You’ll also need to know which directory Squid uses for it’s cache. This is usually something like /var/cache/squid. If you do not allready have a dedicated account and group create them now. If you’re using Red Hat or Gentoo, the proper account should already be created and you can safely skip to Listing 15.

Listing 12. Creating the squid user and group
root#  groupadd squid
root#  useradd -g squid -d /var/cache/squid -s /bin/false squid

With the account created it’s now necessary to tell squid to use it as it’s running account. Add or confirm the following lines exist in /etc/squid/squid.conf .

Listing 13. Squid configuration file: /etc/squid/squid.conf
cache_effective_user   squid
cache_effective_group  squid

Some permissions need to be set in order for the new squid user to access everything else it needs. One of the most important places is the pipe that winbind uses to contact the domain. Squid must have access to this pipe so it can also contact the domain.

Listing 14. Setting permission on the winbind pipe
root#  chown root:squid /var/cache/samba/winbindd_privileged
root#  chmod 750 /var/cache/samba/winbindd_privileged

Now some final permissions for the cache directory and log files. Remember to substitute your corrects paths if they are different then the ones below.

Listing 15. Setting final permissions for the squid user
root#  chown -R squid:squid /var/cache/squid
root#  chmod 770 /var/cache/squid
root#  chown -R squid:squid /var/log/squid
root#  chmod 770 /var/log/squid

The last file to edit is your main Squid configuration file. You must configure NTLM authentication and create and ACL to take advantage of it. Add the following lines to your /etc/squid/squid.conf file.

Listing 16. Squid configuration file: /etc/squid/squid.conf
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 2 minutes

auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 5 hours

acl NTLMUsers proxy_auth REQUIRED
http_access allow all NTLMUsers

I would suggest keeping an eye on Squid’s cache.log for lines that look like:

Consider increasing the number of ntlmauthenticator processes to at least 13 in your config file.

I’ve seen the suggested increase as high as 25 in my logs, meaning only 5 child processes are occasionally becoming seriously backed up. Increasing that number will ensure authentication requests are handled more effeciently. After some minor testing, I settled with replacing the line from the previous example with:

auth_param ntlm children 15

Remember to place your http_access line in the appropriate sequence with the rest of your configuration.

For good measure you may want to clear and rebuild your Squid cache.

Listing 17. Clear and rebuild the Squid cache
root#  squid -z

And finally, start the Squid server.

Listing 18. Start the Squid server
root#  /etc/init.d/squid start

And that should be it! The best way to test your setup is to open Internet Explorer and browse the web. Check your Squid logs after hitting a few sites and you should see your network userid listed along with all of your recorded accesses. You can view an excerpt from one of my logs here. Notice my username in the eighth column of each line.

FINAL NOTES

Like anything else, Squid with NTLM authentication has it’s good points and bad points.

PROS:

  • Enables tracking proxy traffic by user (userid) insead of by machine (hostname or IP address)
  • Ensures that only valid domain users are allowed to access the web through the proxy

CONS:

  • Only works with Internet Explorer. Users of other browsers will have to manually login to the proxy server when they first open the application.
  • Mobile users sometimes do not have their laptops joined to the domain. This means there’s no domain authentication to pass on to the proxy and they must authenticate manually.
  • Third party applications that are configured for the proxy will most likely have to be manually authenticated. An example would be watching streaming video in Quicktime.
  • Every time a user requests a site it will be logged as a TCP_DENIED untill they’re authenticated with NTLM. This will make your logs grow a bit quicker.

Depending on how you look at it, the cons may not be problem areas at all. For instance, if you don’t have that many mobile users then laptops may be an issue you can deal with easily. Fortunatly, this is a very easy process to bypass if you find that it isn’t right for your situation. Even after everything has been setup, perform the following to revert to your old setup.

Listing 19. Restoring your old Squid configuration
root#  vi /etc/squid/squid.conf
[ comment out the single new http_access line]
root#  squid -k reconfigure

19 Responses to “Integrating Squid and Samba3 with NTLM authentication”

  1. td_sivakumar says:

    Sir,

    Realy it is a very good effort.The site helps me a lot to configure suqid with NTLM authentication.The steps are very easy to follow so the configuration made very easy.Thanks for your effort.

    Siva kumar
    system administrator
    Amrita vishwa vidyapeetham,
    Coimbatore,
    India

  2. arunrajendrantdpa says:

    Hi sir,

    i followed up to listing 16.
    the following acl is not defined in any where
    “acl NTLMUsers proxy_auth REQUIRED
    http_access allow all NTLMUsers”.

    so after configuring this one squid is not working.
    can you pls clarify this one?

  3. samerk says:

    thank you guys for this documentation it’s quite helpful when configuring Squid with NTLM.
    However i have a couple of questions regarding clients that are not joined to the Active directory DC:

    1- a NON-joined client using IE will have to log on using realm/username and passwd. Is there a way to make him authenticate with only his username and passwd ?
    NB:It works fine with other browsers such as Firefox.

    2- If you use IE with this NTLM auth (on an NON-joined pc) and select the ’save password’ checkbox the password gets stored in the registry as if it was for a network location. To delete the record you will have to run
    “rundll32.exe keymgr.dll, KRShowKeyMgr”
    This is causing real problems to users. Have you encountered this? and were you able to figure a way out?

    Thanks again,
    Samerk

  4. cam says:

    hi there,

    Thanks for this nice tutorial !

    I have a question regarding the authentication part.
    What happens if inns-fs1.richmond.rich.edu is dead ? is there a way to fall back on a backup DC ? Ex: if inns-fs1.richmond.rich.edu no longer alive, then query inns-fs2.richmond.rich.edu

    Thanks,
    Fred

  5. sowr says:

    great,
    thank you for this info :)

  6. Gareth says:

    step 5. failed no matter what I did, so i changed it to
    net rpc join -U Administrator
    and it worked fine.

  7. Ship says:

    Great. very useful
    Bokmarked

  8. Zashkaser says:

    Hi, good post. I have been woondering about this issue,so thanks for posting. I’ll definitely be coming back to your site.

  9. Many thanks for this nice tutorial

  10. Andrew says:

    Thanks for this tutorial, been trying to get this to work for well over a week but finally got it working after resolving the winbindd_privileged
    problem

  11. icecreamdaddy says:

    wtf.. there’s a whole lotta questions but no answers.. that sucks.

  12. [...] Squid autenticando no Windows utilizando grupos do AD – Integrating Squid and Samba3 with NTLM authentication – Integrando autenticação do Squid ao Active [...]

  13. [...] Ubuntu 8.04 autenticando no AD do Windows Server 2003 – Integrating Squid and Samba3 with NTLM authentication – Integrando autenticação do Squid ao Active [...]

  14. Kunal says:

    Dear,

    Wondering how can we track the current NTLM logged in users?
    Any Guesses experts?

  15. sucking crap out of my car tomorrow! I ;ll let you know how it goes. Assuming it works well, I may even keep it in mind for future baby showers, as it would make a louis vuitton fake or real http://louisvuitton-fakeluggage.blogspot.com/

  16. I didn’t know about this until I read your post. Thanks for the information.

  17. a says:

    I am curious to find out what blog platform you_re utilizing?

    I_m experiencing some small security issues with my latest
    website and I_d like to find something more safe.
    Do you have any recommendations?

  18. Love this world!

Leave a Reply