openldap and kerberos integration on centos6.2
 

Hi , I am trying this for the first time to integrate openldap with kerberos for authentication purposes. All the docs that I found online are too complex to be followed under my scenario which is a fresh Installation.Can someone please guide me to setup a system described above or any link to a doc which explains this in easy way.
My second question; Is this possible to install openldap and kerberos server on the same machine? Thanks for your support.

Zulkifal

we really aren't here to guide you. it is certainly possible, and note that in reality the two systems have *NOTHING* in common. they just coincide. So your configuration of one system will not relate to the other at all apart from happening to reference the same usernames etc.

Note that you can do a full centralized user system with ONLY OpenLDAP. you do NOT need Kerberos at all. LDAP is perfectly capable of doing user authentication by itself.

Thanks Chris, I guess this explanation is enough for me , as I was confused about integrating both because I read it in a few articles which claimed that they both work together as a perfect authentication system.

Zulkifal

yes, they work very well together, but they don't actually interact. the system goes to ldap and gets account data, and then takes that username and goes to kerberos to validate the users password, each system not knowing / caring about the other.

ok after a while i have configured MIT kerberos and openldap both together but my kerberos and openldap are running on different servers. Everything worked fine until I stored my kerberos within ldap database with " kdb5_ldap_util " command.Now when I start my kadmin and krb5kdc service It doesnt start. Any ideas? It says cant contact ldap server

That is ok.

There is is bit of a terminology difference there. Kerberos provides authentication. LDAP provides authorization.

I would suggest first getting Kerberos to work to allow logins. Authorization is then done by verifying that the login is valid, home directory is valid, AND the ability to get a service ticket for the local host... (this requires a keytab for the host being logged into).

When that works, you can look into the independent facility of LDAP.

The advantage Kerberos has over LDAP alone is that passwords are NEVER sent over the wire, except when setting the initial password, or replacing the password (kpasswd utility, or during expired password handling). LDAP can do a good job when users home directories are on network based storage by identifying where the storage is. It is less useful (next to useless in fact) for local logins.

why is LDAP useless for local logins? I've never wanted to do that, but if the account exists in LDAP, then it can be authenticated to, regardless of where the user data comes from - files or LDAP itself.

The only purpose for a local login is having use of the system. Local logins also mean local home directories...

The only use for LDAP at that point is to give out passwords...

If the login is local, then LDAP is of no benefit as the account is already local..

It also introduces an additional failure point - if, for some reason, the network is down, so is your local login... And you just might require the local login to diagnose the problem...

The next problem is that the password (even though hashed) is still sent out over the network. The connection may be encrypted to the host... but if the host gets penetrated, so do the passwords on the LDAP server.

This last is one of the problems Kerberos addresses - since no passwords are sent over the net, it isn't possible to penetrate the KDC by penetrating a host. All you get is the keytab for that host. A problem, but a constrained problem. To get a users password you have to get the user to login on the penetrated system - and that restricts the vulnerability to just the users logging in directly on that system. Remote logins (ssh for instance) don't do that - they use credentials issued by the KDC (encrypted with the hosts key), and not the users password. Any forwarded credentials also do not include the users password...

only do passwords? point of failure? How is this any different to the functionality that a KDC provides?

Centralised passwords for local accounts can have a use, but that wasn't the point. Point was that IF it's the case, then LDAP can do it just fine, just like Kerberos can.

I get that the password is sent over the wire, but with TLS encryption I think that's a non-issue, and it's hardly like Kerberos is fully secure. If someone gets into your Kerberos secured systems, ALL of your machines are potentially up for grabs.

Yes, it can. But as I said, for local accounts only it is nearly useless.
No - TLS encryption only protects the session - but if the host is penetrated, then that protection no longer exists, and that host can retrieve the entire list of passwords.

In the case of kerberos, penetration of the host only gets you a host keytab. Serious, but only for that specific host. It does NOT get you anything on the KDC. No passwords ever.

The only way to do that is to get into the KDC itself. And normally (properly) there are no services on the KDC BUT Kerberos itself. The KDCs I've managed only allowed local logins, so you have to physically walk up to it. With no other services, the KDC is VERY isolated from network attack. And standard physical protections would prevent unauthorized users from doing that.

How can you retrieve a list of passwords from LDAP? that's not true at all, outside of a very poorly designed central server. LDAP isn't NIS.

Also if the host is penetrated, then you'll have a KRB5 ticket already and you can bounce from host to host to host, with no need to care about the passwords in the first place - so no one cares if you don't have them. With a password being required explicitly, you still need that password to get to the next host.

And whilst it's not relevant really, we did have a use for a local account with a central password - Oracle. We can start an Oracle service on boot from init scripts without authentication. However any DBA (without root access) wanting to access the oracle account through sudo needed the oracle account password held centrally. that was useful.

Just go through the local password file or home directory list, and retrieve them one at a time. LDAP is equivalent to NIS+ as far as that goes. Neither is perfect. LDAP has the benefit of working better over networks. But any service that gives out passwords is not the best thing.

Not necessarily. IF you steal a krb5 user credentials, you only get access to the users account for a limited time (usually 8-10 hours, sometimes less), after which the credentials expire.

And it is entirely possible to disallow forwardable tickets, which will require you to get new credentials before connecting to the next host. To get the new credentials requires you to already know the password (which is only used locally to decrypt the credentials for use). And for local accounts, I recommend using nonforwarding credentials.

But then, if the account is valid on multiple hosts, then it is no longer exactly a "local" login anymore. True, each host still has a unique home directory... but it does become a borderline case.

One place I worked had the KDC issuing credentials for only 15 minutes to users on untrusted networks (educational sites and such), but allowed 4 hours for more trusted networks (corporate departmental nets), and 10 hours for internal clusters. I don't know if these controls made it back to MIT though...

Nope, you're wrong there... Are you thinking about storing NIS password maps in LDAP? LDAP does / can not disclose passwords when you're hitting it through PAM. The client binds to the LDAP server with the appropriate mapped DN and the password. If the password is correct, then they bind successfully. That success is then used as an acceptable login. The client NEVER validates the password in any way.

Ok. Forgot that.