The last "innovation" I'm aware of in this area, is skolelinux/edulinux work with packaging samba/ldap/kerberos/lts in a easy(ier) to manage package for Debian:
https://wiki.debian.org/DebianEdu/Documentation/Wheezy/Archi...
The last "innovation" I'm aware of in this area, is skolelinux/edulinux work with packaging samba/ldap/kerberos/lts in a easy(ier) to manage package for Debian:
https://wiki.debian.org/DebianEdu/Documentation/Wheezy/Archi...
Central auth, auto certificate deployment, encryption by default. The nice bits are Windows only unfortunately.
Even if I was willing to introduce a w2k8 server -- it's hardly trivial to integrate across infrastructure. Eg: set up client auth for ssh in such a way that online verification of certs against a list of cancelled certs works -- and that there are no other ways to authenticate to ssh servers.
I absolutely agree that AD is one of the best things MS ever rolled out -- it's unfortunate they a) broke (or bent) some standards when doing it, and b) just like .net and sql server are great platforms, they're not for me (any more) -- I'd much rather play in an open environment. Mostly so I'm not dependent on a single entity for continuation of services and development.
I know RedHat have their directory server, and Samba4 has basically copied some of the architecture from AD (roll up LDAP, cifs, kerberos all in an integrated set of services) -- and that's great. I'd still like to see a single open design that actually works (and that last bit means it needs to be tested across heterogeneous environments).
I don't think such a system would actually be too hard to implement these days, we have a lot of great components that just need to be fit together and "blessed" with some rigorous packaging and documentation. Perhaps the "best" way would be to wrap kerberos principal key exchange in a public key transport of some sort (but at that point you'd really only be using kerberos for backwards comparability, you'd have moved the trust and authentication implicitly to your CA infrastructure (possibly with a low lifetime of service tickets) -- which could be good or bad depending on your point of view).
Basically what I want, is to have a way to throw a (most likely private) CA-cert on a new box, and then have that box request a cert via on-line csr to a gateway -- that gateway should then be able to forward the csr to the CA (which for high security setups should be air-gapped, for most settings might be a daemon running on the same box). Then once machine certs are set up, probably use service-certs for services (if this sounds a lot like kerberos, that's not an accident) -- or just assume one service per (virtual) machine.
For users we'd need something similar, and we'd need a working online check for validity that defaults to disallow, probably with some caching for local login on laptops/workstations to be able to to some* authentication even when offline (obviously configurable, depending on use-case).
After the years of attack on kerberos (among others) I think many of the risks are well understood -- the challenge is just to build something that is simple enough, but yet works. Dictate a single format for certs, possibly a very limited set of algorithms (but history seems to indicate that some sort of visioning is needed, maybe explicit "valid sets" rather than open negotiation?).
Anyway, sorry for the post, probably should've been a blog post :-)
the problem is having tools that communicate with each others and an easy setup.
yeah, SAML kinda sucks to use too.. and works like kerberos anyway. OpenID, Hawk, etc - also in fact work exactly the same.
As mentioned up-thread MS AD does a great job of enabling in-house CA and management -- and it's mostly that I want. I want to use certs for auth most places, and I want it easy! Openssh have shown that public key auth doesn't have to be hard -- but also doesn't have a very compelling story around managing access. The new cert-system might be an improvement -- but it absolutely needs some infrastructure around it to be easy to deploy (and verify).
if it changes, it warns you.. but in most cases you're going to know why it changed or just accept the change anyway (which is a problem when you admin 10000 servers of course as the warning might be a real issue)
central trust/revocation is still an issue everywhere to this day, i think. both technically ("my client trusts this, but do i?") and from the useability pov.
Well, yes and no. Do you mean the new cert stuff that's in standard openssh? Which has stuff like:
The marker is optional, but if it is present then it must be one of “@cert-authority”, to indicate that the
line contains a certification authority (CA) key, or “@revoked”, to indicate that the key contained on the line
is revoked and must not ever be accepted. Only one marker should be used on a key line.
While certainly simple, it doesn't strike me as very manageable.Or did you mean the x509 patch?
I do indeed like kerberos - but I still want a straight forward and reasonably robust framework built on certificates.