# Kerberising my network

## casso

Hi,

I have a small network as a test bench of my skills. I am trying my best to make it as secure as possible. I haven't yet got IPSec going, but will later. I have what I would call average firewall scripts and a handful of network services.

What I am trying to do is make every network service require authentication where I feel it's necessary (eg: I don't need auth to let my ntp client update the time) so that I can have tight control. I would prefer, in all cases to use Kerberos. The problem is finding services and clients that support it.

So far I have the following services working with Kerberos:

SSH, although I mainly use public-private keys

Logins through the use of pam_krb5

LDAP access, mainly for modifications

Most other services have PAM support, which can use the pam_krb5 module for authentication of those services, and not need a seperate password database. I do understand that this does not provide the secuirty of Kerberos any more, and that is something I would like to fix.

These services I would like to run Kerberos with, but are currently using a seperate authentication method:

HTTP, FTP Proxy with Squid (I don't know if any HTTP/HTTPS/FTP proxy supports Kerberos)

SOCKS5 (I know that SOCKS5 itself supports this, but I need to find a SOCKS5 server that will support it)

CUPS (I still need to allow Samba access)

I do run more services than these, but at the present time, these are the only ones requiring authentication.

In the absense of Kerberos, I would like to use NTLM (via Samba) for Authentication. I know that Squid has NTLMSSP support, but only MSIE supports it, not Firefox which I currently use. I am not using Samba 4, hence I do not have support in Samba anywhere for GSSAPI. I don't have Active Directory either.

The other issue is that I run both Linux and Windows machines. I need both to be able to access these services, and I attempt to use these services directly under Linux (eg: Use CUPS directly for printing, not use Samba and CUPS as the backend for printing from a Linux client).

I know some of this information may not have been presented clearly. I welcome all questions and feedback. If someone can give me an alternate authentication system (such as X.509) that will be as secure as Kerberos, then I am all ears.

----------

## casso

Wow, 45 views in one week and not one post.

Maybe I asked a tough one, or the wrong question. I did have LDAP, SASL and Krb5 all working together nicely at one stage, but I think I failed on something the second time round (probably on the Kerberos side actually) and now it doesn't work. I also had SSH and Krb5 going, but its failing too. I'm looking into it.

I think I can manage to reconfigure these programs, but what I want to be able to do is get some feedback from other users about their use of Kerberos, esp. Kerberos version 5 and their current implementations. I would like to eventually Kerberise my entire network. Even though it is not very big, I hope to learn enough to apply it in other situations.

Any information at this stage would be helpful. At least a post would be nice

----------

## casso

Hi again,

I was wondering if anything has changed out there in the last year. I am still trolling for a proxy server that will support Kerberos authentication. By authentication, I mean using Kerberos V tokens to gain access to the proxy server, as opposed to digest, NTLM or plain authentication. Firefox I believe can support this, but finding a HTML/FTP proxy to request such support is difficult. Is anyone willing to open it up as a project and add a patch to squid with me? Searching the internet for "Kerberos proxy" will certainly not assist anyone trying to attempt the same task as me, and searching for "Kerberos HTML proxy" mainly talks about a proxy server passing Kerberos tokens on for the user successfully.

I haven't managed to find anything for CUPS yet that will authenticate users in the same way mentioned for a proxy server.

My LDAP system has made it back to LDAPv3 compliancy (LDAP/SASL/GSSAPI). I have LDAP and SSH configured to at least support Kerberos authentication, although at present it isn't getting much use. If anyone has any additional Kerberised systems that they have configured, I would like to hear about it.

----------

## think4urs11

I didn't try it yet but it should be possible to authenticate squid against pam and pam authenticates against a kerberos server in the backend.

----------

## casso

Thanks for your reply Think4UrS11. I do know (and have tested) that PAM can be used to authenticate users for squid. Since PAM can be used, any PAM module is allowed to authenticate users, such as passwd, LDAP, or Kerberos. My problem from a security perspective is that the password is sent (as far as I know) cleartext to the Squid server, where the PAM authenticator then uses the username and password to authenticate against a PAM plugin. I want to authenticate using a Kerberos ticket that originated from the client (like Firefox) using GSSAPI for authentication.

Here is what should happen:

Client requests a page from proxy server

Client gets an unauthorised response (401 or similar)

Client has a TGT in there Kerberos cache

Client requests a TGS for the proxy server

Client negotiates with the proxy, using tickets for authorisation

Client becomes authenticated

Client uses proxy server as normalThe important thing here is that tickets were used for authentication, not passwords of any kind. The nice thing about Kerberos is that no password, or password equivalent is ever transmitted over the network. It also assumes that no servers or clients can be trusted, and that all clients and servers must authenticate each other. The only trust is with the Key Distribution Center.

I hope this clarifies what I mean by authenticating a user with Kerberos (GSSAPI to be specific) to use a HTTP/FTP proxy. I am not trying to insult anyone, it's just that I don't think any such proxy server exists as of yet. Problem is I know there will be more services that I will want to configure for GSSAPI authentication to allow clients authenticated access.

I am keen if anyone is interested to add code to a proxy server to allow GSSAPI authentication. I know the RFCs are in place to do so, but I don't believe  any proxy server has such support. I am hoping someone out there can prove me wrong. If I can't be proved wrong, who would be willing to assist on adding the appropriate infrastructure to a proxy server?

----------

## casso

Just read: Squid Negotiate Authentication

This is a starting point for what I'm looking at. However, this is aimed at using GSSAPI with SPNEGO. This is a Microsoft Active Directory setup. In other words, it is not the traditional GSSAPI I am referring to, but it MAY work. If anyone has attempted to use negotiate authentication under Squid, I want to hear about it. I will also try to contact a squid developer to see if it is possible to get plain GSSAPI authentication into Squid as well as negotiate.

I am still stuck on authorisation of CUPS users. I know I can use PAM, but this causes the same issues addressed with Squid basic authentication. I would again like to authenticate users for CUPS with the same GSSAPI method described in my last post for Squid. Any ideas?

----------

## Herring42

I'm using kerberos for NFS4 authentication, where it seems to work just fine!

Is there a way of using your kerberos ticket with kmail and firefox to access mail and web without logging in again?

Cheers.

----------

## casso

 *Herring42 wrote:*   

> I'm using kerberos for NFS4 authentication, where it seems to work just fine!
> 
> Is there a way of using your kerberos ticket with kmail and firefox to access mail and web without logging in again? 

 

I am not sure is the short answer to this question. The easiest way to determine this would be to find out where Firefox expects to find your Kerberos TGT for a user, and if NFSv4 puts the TGT in the same location. It would also need to be stored in the same way, or a compatible way with Firefox. I don't think the storage method is going to be a big deal, Firefox should be able to hanlde a multitude of different accesses to the TGT.

Then again, if NFSv4 and Firefox are built using the same Kerberos library, I would assume that you could reuse the TGT for Firefox. Using a library to gain and store the TGT would make the entire process rather independent of how NFS or Firefox handles tickets. The same would apply to Kmail.

Do you currently have a way to test if the TGT you gained via NFS works with Firefox? If so, can you check if your NFS client (or pam_krb5) is using the same library as Firefox for Kerberos. I don't know if NFSv4 requires you to gain a TGT via PAM, or if you gain it by attempting a logon to a NFSv4 compliant server.

==========CUPS AND SQUID==============

I found out that CUPS v1.3 supports Kerberos authentication out of the box. This made me look like a bit of a fool asking around about CUPS and Kerberos. What I did find is that (at this moment) CUPS v1.3 is marked unstable in portage. I will test CUPS and Kerberos later. I also found that CUPS lists the Kerberos (GSSAPI to be specific) authentication method as Negotiate which was quite interesting.

This should mean that the negotiate method under Squid will hopefully support GSSAPI from a Firefox client or similar, allowing my Linux clients to authenticate to the proxy server via Kerberos without a hitch. I just hope that the Samba 3 module that I will be using as a backend authentication module to Squid makes this possible. I was told (by Andrew Bartlett) that Samba 4 would work even better for this. I will keep you posted once I get a chance to check.

----------

## manaka

I haven't read this thread until today  :Sad: .

Very interesting work!  :Smile: .

I haven't tried setting this sort of things yet. But it's in my TODO list. I will post if I find anything.

BTW, It would be nice writing a guide about Kerberos SSO (the Gentoo way  :Smile: ). This could make this topic get more attention/testing/patches...

Good luck...

----------

## da5idii

I am trying use kerberos and nfsv4 but i can not seem to get it to work, when whenever i try to mount i get:

mount.nfsv4: Permission denied,

the system log read:

rpc.gssd: WARNING: Failed to create krb5 context for user with uid 0 for server XXX

rpc.gssd: WARNING: Failed to create krb5 context for user with uid 0 with credentials cache FILE:/tmp/krb5cc_machine_XXX for server XXX

rpc.gssd: WARNING: Failed to create krb5 context for user with uid 0 with any credentials cache for server XXX

Can anybody help please

----------

## casso

I would suggest making sure your kvno values are consistent. Each Kerberos ticket stored in the keytab and in the Kerberos database has a key version number attached to it. If that version number does not agree for the same ticket in all locations, then you will get problems with authentication via Kerberos. Error logs generally don't point this out for you. Can you run klist immediately after you get this permission denied error and post it please.

I unfortunately don't have any NFS experience beyond some basics. NFSv3 and NFSv4 do sound promising when it comes to Kerberos authentication. I have mainly been using CIFS for my network at this stage, which does have some sort of Kerberos support, but I am hazy on the details.

As for the rest of my network, I haven't yet implemented proxy authentication via Kerberos, although I have been told that modifying the existing negotiate authentication mechanism using the ntlm_auth plugin for squid may be the answer to Kerberos+Squid, especially when using Samba4 code. Squid really needs a native Kerberos authentication plugin, which I am sure could be created by making modifications to the current ntlm_auth code from Samba, and asking for the Samba team's assistance along the way.

Anything that supports SASL should be able to support Kerberos straight up. To be strict in the definition, it should support the GSSAPI mechanism under SASL. My current mail servers (Postfix for SMTP, Cyrus-IMAPD for IMAP) both support SASL. I also make use of SASL with my LDAP server, although not many systems are directly performing a query against the LDAP server at present.

If you are making use of Kerberos over a reasonably sized network, I would suggest running a DNS server that has A and PTR records for all your servers, plus SRV records for your Kerberos servers. Saves having to specify who your Kerberos are to each machine.

Services currently Kerberos capable (not necessarily configured):

SSH

LDAP

IMAP

SMTP

CUPS

Services yet to support Kerberos natively:

Samba. To my knowledge it is only for use with Microsoft AD style authentication

Squid

I had also wrote that my network should fall back to NTLM authentication when Kerberos was not available. I would actually like both to be available for most services. All SASL systems can make use of an auxiliary plugin for NTLM, although I have not yet tested it. Current services supporting NTLM authentication:

Samba

Squid

IMAP

SMTP

CUPS via Samba

To be honest, CUPS does not perform any authentication via NTLM. The print traffic is sent to Samba which performs NTLM authentication, and is sent via Samba to CUPS. I think I will need to configure CUPS to accept traffic on the localhost unauthenticated to allow Samba to print via CUPS, but force all other systems to authenticate via Kerberos when speaking directly to the CUPS server.

----------

## da5idii

Well i finally got it working, i dont really know waht i was doing wrong, i jsut did it enough that i got it to work. How do you authenticate LDAP against kerberos. i am using kerberos for pam authentication and ldap for user accounts. for some reason i am having problems ssh into my server, it seems to be authenticating but the session is  closed immediately by the server.  I am also curious about samba authentication against kerberos and ldap, and experience?

----------

## casso

So you have three points where you want to authenticate using Kerberos. 1 is LDAP, 2 is SSH and 3 is samba. The bad news is that Samba outside of an AD environment (to my knowledge) cannot use Kerberos for authentication. I would suggest using NTLMv2, which can be specified via the sec=... option when mounting via CIFS.

LDAP and Kerberos.

Firstly, I assume that LDAP has been built with SASL support, and SASL has Kerberos (and possibly LDAP) support. When a user attempts to authenticate to an LDAP server via SASL, their current username is used for that authentication. This is okay for the authentication side, but LDAP needs to know what user this is in the directory tree. LDAP doesn't have a direct concept of a user, but it has the concept of an object representing a user. What you need is a mapping between your SASL username, and an LDAP object for that user. The following link (http://en.tldp.org/HOWTO/LDAP-HOWTO/sasl.html) is to the LDAP HOWTO on TLDP.org. It shows lists the following regular expression match for transforming an SASL username into a path to a directory object.

sasl-regexp uid=(.*),cn=rdnt03,cn=DIGEST-MD5,cn=auth uid=$1,ou=People,o=Ever

What this means is when the string uid=...,cn=your.domainname,cn=SASL-AUTH-MECH,cn=auth comes out of SASL, it should map to uid=...,ou=People,o=Ever

You mileage for this string will vary, but the part you do need to know is that the SASL-AUTH-MECH is GSSAPI. My sasl-regexp string is:

sasl-regexp uid=(.*),cn=home.net,cn=GSSAPI,cn=auth uid=$1,ou=Users,dc=home,dc=net

SSH and Kerberos.

You should log onto your box running SSH and start a new SSH Daemon in debug mode, and in the foreground. You will need to change the SSH port to something else. Then connect a client via SSH to this new port, also in debug mode. The easiest mistake is that the permissions on the user directory (usually /home/username) is not set properly (should at least be 0700), or that the directory does not exist. If you are having authentication issues with Kerberos, the debug mode should show this up. Please check the output of klist on the client for a valid TGS. you should see something like:

host/ssh-server.example.com@EXAMPLE.COM

Without that line, the client does not have a valid ticket to use the SSH server. If you do get this ticket, check the version number from klist matches the version number stored both in the Kerberos database, and in the keytab file that SSH is using. You can use ktutil to read a Kerberos keytab and gain the list, and the getprinc command of kadmin to list the particular Kerberos principal for you SSH server. You may need to read the man pages for specifics on the commands.

When I get it done, I will post some information on how to store the Kerberos database inside LDAP itself. Stay tuned.

----------

## VinzC

Hello.

May I ask you how you've setup your system?

I'd like to setup a system that is similar to yours, if I understood. I'd like to use Kerberos only to authenticate users when they log on and LDAP to retrieve the loginShell, homeDirectory, gecos and groups to open the session. BTW I'd like to forbid anonymous access to LDAP server, GSSAPI only.

So I'm currently struggleing with PAM and LDAP to have login grab the required information from the sources that I want: userID/password from Kerberos; shell, home directory, and groups from LDAP -- password field being blank for all my accounts.

Is it what you've done?

----------

## casso

The short answer is that you need to use pam_krb5 to authenticate users, and use nss_ldap to gain the user information that you are after. LDAP can store POSIX user account information like that found in the /etc/passwd file, while Kerberos can store the tickets required.

This is exactly what I have done so far. One problem that you are likely to face when using OpenLDAP client libraries is that nss_ldap will loose its connection to the LDAP server and keep reconnecting. I believe that either the Gentoo build of the software is causing a problem (possibly due to a hardened toolchain on the client), or that the OpenLDAP libraries are buggy, which is a complaint I have heard before.

If you want assistance with LDAP layout or configuring Kerberos as a system, then I would suggest you open another thread. If you want assistance on configuring either nss_ldap or pam_krb5, then feel free to ask here. The configuration for both of these is rather straight forward.

----------

## VinzC

Thank you so much for replying, casso.

What I'd like to do is to setup a single sign-on solution with Kerberos and LDAP so that the Kerberos ticket is reused at the logon time by nss_ldap to bind to the LDAP server. I've successfully built and used all the pieces independently -- e.g. use a kerberos principal to logon but using a local account with the same name or accessing LDAP using SASL/GSSAPI only while logged on with a UNIX account.

 *casso wrote:*   

> If you want assistance on configuring either nss_ldap or pam_krb5, then feel free to ask here.

 

So, yes, that's what I'd like. I'm currently trying to make nss_ldap reuse the Kerberos ticket as you mentioned. The problem is I don't understand what I'm doing for I haven't been able to find a complete step-by-step guide.

Till now I've succeeded in having users logon [with their Kerberos principal] only after I run kinit as root, passing any credential to the latter command -- hence changing /etc/nsswitch after logging on as root. I've also been able to store the generated ticket cache as /etc/.ldapcache for instance but my attempts to renew it with kinit always failed.

Unless there is a smarter way of course.

----------

## casso

A service account may be your solution!

Although it is for a different purpose, I require a user account just to perform syncing of LDAP between two machines. At present I use an ldap password, but later (when I get time) I will use a Kerberos ticket that will be refreshed by a cron job every hour.

In your case, you could have a user setup that can gain read only access to all POSIX information required from the LDAP server. This is generally going to be information similar to /etc/passwd and /etc/group. Nothing needs to be written by this user, and only the bare minimum of information need be made available. You can configure nss_ldap to bind as that user, but I am not quite sure how Kerberos ties in. Again ticket renewals can be done via cron, but you will need to add a kinit line for the service account in /etc/conf.d/local.start, otherwise you may be waiting a while to login.

----------

## VinzC

 *casso wrote:*   

> In your case, you could have a user setup that can gain read only access to all POSIX information required from the LDAP server. This is generally going to be information similar to /etc/passwd and /etc/group. Nothing needs to be written by this user, and only the bare minimum of information need be made available. You can configure nss_ldap to bind as that user, but I am not quite sure how Kerberos ties in. Again ticket renewals can be done via cron, but you will need to add a kinit line for the service account in /etc/conf.d/local.start, otherwise you may be waiting a while to login.

 

I see. One thing I don't understand is why it is difficult/impossible to use the ticket of the user who logs in. All in all, setting up a dedicated principal for just binding to LDAP and read into the posixAccount has the same disadvantages as, say, storing an encrypted password in a file for later use. Especially I imagine running kinit in local.start would require the password to be put there in clear form, am I right?

BTW should that specific principal have a password or not? My failed attempts were made with a ticket cache of a principal that had a password. Do you have an example of a kinit command that is used to refresh a ticket?

I've tried these:

```
kinit -R -k -t <path to a keytab> -c <path to the ticket cache> my_principal

kinit -R -c <path to the ticket cache> my_principal
```

Both fail -- IIRC the error message says the Kerberos server cannot be contacted in the first case and the ticket cannot be renewed in the second. For the first example I've tried creating the keytab file on both the client and the server (kadmin: ktadd -k <path to the keytab> my_principal).

----------

## casso

Sorry I have not replied to you VinzC.

I have not tested any configurations with Kerberos ticket caches, so I cannot really speak on the subject. Is it better to have a ticket cache that is readable only by root and the user that is used to lookup LDAP than to have a script that enters the same users password into kinit every hour to renew the ticket? Both of these files (script and ticket cache) are locked down from view of prying eyes, so that should improve the security.

As for asking about using the user's Kerberos ticket to authenticate to LDAP, you would need to lookup the user account to make sure it exists before you allowed the user to authenticate. Since you cannot authenticate yet to LDAP (you have no Kerberos ticket) you cannot authenticate the user with Kerberos. You have a chicken before the egg problem.

Cannot authenticate to Kerberos because no user list from LDAP available

Cannot get user list from LDAP because cannot authenticate to Kerberos

Hope this helps answer some questions for you. If you have made more progress, please let the community know about it.

----------

## notHerbert

 *casso wrote:*   

> Again ticket renewals can be done via cron, but you will need to add a kinit line for the service account in /etc/conf.d/local.start, otherwise you may be waiting a while to login.

 

Doesn't the max_renewable_life in the kdc.conf cause the tickets to be automatically renewed?  My tickets are always automatically renewed without any cron scripts, therefore no need to put sensitive data in a startup script e.g. local.start.

----------

## casso

I believe that you still needed to manually renew the TGT without credentials, which would need to be done via cron. The max_renewable_lifetime can be set per principal if I remember correctly, so you should be able to set the TGT and possibly the particular TGS as always renewable.

Problem: You still need to initialise the TGT. By this I mean that you still need to put credentials information somewhere to get the TGT in the first place.

TGT: Ticket Granting Ticket. The base ticket that allows you to gain other tickets, especially those to services. In this case, the TGT is gained by the principal (the user) that initially authenticates to Kerberos in order to gain a TGS to query LDAP.

TGS: Ticket Granting Service. The ticket that allows a principal (a user) to access a service. In this case, the TGS is for the LDAP server that is being accessed.

----------

## notHerbert

Thank you casso,

If I don't specify a keytab in ktadd, then the credentials cache is stored in /tmp/xxxx, and of course it is deleted during a reboot. 

However if I specify a keytab 

```
kadmin.local -q "ktadd -k <keytab file> <principal>"
```

Then the credentials cache persists even through a reboot and the tickets are automatically renewed seemingly forever.

I'm wondering if this persistent renewal is because (in my setup) the "max_life" and "max_renewable_life" are set to the same value, and perhaps because I'm only using krb5 to authenticate networked users login against LDAP. 

At any rate, thanks for this really nice thread. It's very helpful and thought provoking.   :Smile: 

BTW: I must add that I'm a total nOOb in kerberizing. That's why I'm questionning rather than answering.  :Very Happy: 

----------

## dambacher

Hi there

I'm on kerberizing my network, too.

I managed authentication using pam-krb5 and I am successfully using nfsv4.

But squid and cups still don't work.

I did not try ssh until now.

This is what I found out:

about squid:

squid 3  can work with kerberos tickets - if the browser provides some.

From the net I googled that  your Browser needs to show a ticket for http/squid-server@your.realm

firefox needs to be enabled to do negotiate-authentication. Go to about:config and search for 

```
 network.negotiate-auth.delegation-uris

 network.negotiate-auth.trusted-uris
```

and set your uri there. this should look like .your.domain.somewhere, maybe *.your.domain.somewhere

I see that squid will get this ticket but it still leaves errors and does not authenticate.

about cups

cups 1.3 will accept kerberos tickets, but per default  ipp/your.cups.server@your.realm

now if you use your browser it will maybe send http/your-http-server@your.realm (see above)

so I tried to change cupsd.conf:

```

GSSServiceName HTTP
```

and I saw that the browser sent a ticket and cups got a valid ticket for myusername@my.realm

But then it failed because it could not find myusername@my.realm in my password/ldap. 

The help sais it would remove the realm for lookin up the username, but my ldap debug sais it did not do that.

What I did not try is what happens if I use ipp services (like the command lpstat -t)

Im still trying and will report any status changes.

/dambacher

----------

## casso

Thanks for the reply. It has been a while since I have expanded on my Kerberos configuration, but should be moving on it next month.

Will get back to everyone then.

----------

