3 ms·

Some people use Kerberos instead of LDAP but there's far less people that have actually rolled out a Kerberos implementation that's not related to Active Direct

Some people use Kerberos instead of LDAP but there's far less people that have actually rolled out a Kerberos implementation that's not related to Active Directory than LDAP. Either way, LDAP and/or Kerberos are just re-inventing wheels that have not a whole lot of value in re-inventing / "innovating" partly because disparate identity and authorization management systems are an immense pain to deal with scaling beyond a small to medium size company and everyone would rather use what's well known first before they think they're smart enough to roll their own. This is pretty typical with developers versus systems management folks though culturally though I'd gather. It just pisses me off when I have to fix something some smartass thought "simpler = better" meant that he should roll his own thing instead of learning how people do it first and THEN rolling his own.

jpgvm 12y ago
Kerberos is also acceptable, it is however much more complicated than LDAP for the average sysadmin to understand. You also need to teach your users how to get kerberos tickets and setup keytab etc. Chances are if you are using kerberos you also have LDAP however.
csirac2 12y ago
The thing about kerberized ssh that I've wondered, do you really want your kerberos session to open up ssh access to all the boxes in the enterprise you have an account on?
- devonkim 12y ago
  I'm not quite sure what you mean with this concern but Kerberos is really flexible and a Kerberos realm could act a lot more like roles than by domains (which is the typical correlation). Most enterprise networks I've worked with are extremely fragmented from decades of competing business units rolling their own thing and so the default in most enterprise networks is already quite restricted in many respects, and that is ironically a bit of a help for security by reducing the impact crater of an intrusion. Also, we have plenty of different accounts used by one physical user all the time, so nothing keeps administrators from requiring different accounts for different roles on top of realms. I don't necessarily mean that you need to create user1.support and user1.dev in the same domain but Kerberos solves a lot of problems that ssh alone just doesn't answer, which is a big reason why I reach for that after I have an ok ssh setup. Nothing says you can't put resources in multiple Kerberos realms either. Then you can establish a digraph of trust chains across Kerberos realms to transfer tickets across realms based upon some business rules. There's many reasons that Active Directory (LDAP + Kerberos + some magical bits of quirks and features) is the gold standard for large corporations and the reason is not "nobody got fired for buying Microsoft."

jpgvm 12y ago

Kerberos is also acceptable, it is however much more complicated than LDAP for the average sysadmin to understand. You also need to teach your users how to get kerberos tickets and setup keytab etc. Chances are if you are using kerberos you also have LDAP however.

csirac2 12y ago

The thing about kerberized ssh that I've wondered, do you really want your kerberos session to open up ssh access to all the boxes in the enterprise you have an account on?

devonkim 12y ago
I'm not quite sure what you mean with this concern but Kerberos is really flexible and a Kerberos realm could act a lot more like roles than by domains (which is the typical correlation). Most enterprise networks I've worked with are extremely fragmented from decades of competing business units rolling their own thing and so the default in most enterprise networks is already quite restricted in many respects, and that is ironically a bit of a help for security by reducing the impact crater of an intrusion. Also, we have plenty of different accounts used by one physical user all the time, so nothing keeps administrators from requiring different accounts for different roles on top of realms. I don't necessarily mean that you need to create user1.support and user1.dev in the same domain but Kerberos solves a lot of problems that ssh alone just doesn't answer, which is a big reason why I reach for that after I have an ok ssh setup. Nothing says you can't put resources in multiple Kerberos realms either. Then you can establish a digraph of trust chains across Kerberos realms to transfer tickets across realms based upon some business rules. There's many reasons that Active Directory (LDAP + Kerberos + some magical bits of quirks and features) is the gold standard for large corporations and the reason is not "nobody got fired for buying Microsoft."