There's no good alternative for a locally cashing network filesystem to go with that (although AFS isn't bad) -- and, it's not running on the platforms I use (mostly Debian GNU/Linux -- but bsd would be good too).
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 :-)
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 :-)