Re: Machine authentication and dynamic dns for AD

I was curious if the RH or other contributors have investigated adding
os-level machine auth support into NM, or proper dynamic dns client
support to register with AD.

How does the "OS-level machine auth support" work?
Is this Kerberos + EAP?

Under windoze or mac, essentially kerberos machine account and password are used in peap, feeding those credentials in the dot1x session. If certs are used theoretically it pulls the machine cert for host/$hostname user.

I can get these machine auth creds likely either krb5 direct somehow, or using likewise-open that we use globally for the krb integration anyways using "lw-lsa ad-get-machine password $domain_fqdn" and "lw-dump-machine-acct $domain_fqdn" via rpc (I believe it's using there).

This more or less allows win to resolve $domain_fqdn, chat ad/rpc, pull gpo's, pull patches, let sccm patch it's virus of the day, etc.

Once a user logs in, it transitions to nm and user-based profiles, where in theory would grab kerberos password and pass to the supplicant then. This is where we'd theoretically need some nm behavior to override a system-level auth component before the user logs in, and also a secure method of extracting from krb or other for presentation, without keeping a plaintext password in a keyfile. ;)

Cert challenges are a whole other beast, but as we're migrating to them imminently internally for wired/wireless dot1x, need to begin looking at this too beyond static profiles a user chooses. Mac's use SCEP for cert pulls and inclusion in their keyring for this, linux *should* too likely as everything else still looks activex-y rpc on the normal web cert ca system (damn microsoft).

As for dynamic DNS, I currently have a horrid dispatcher.d script which
does something like:

         if [ "${1/}" != "$1" ]; then
                 logger "Setting Intel reverse DNS for $HOST.$ to $2"
                 # We have to do it in the background or NM-dispatcher will
                 # time us out and kill us.
                 ( kinit -k $HOST$ && net -k ads dns register $HOST.$ $2 | logger) &

Theoretically winbind can do this for itself but it's crap at it — when
we get on the VPN it actually tries to set the DNS to include every IP
address on the system *except* the one we really want¹ :)

Interesting, I hadn't considered the samba suite can probably do this (duh). Thanks for the snippet, I'll play with this and see.

One caveat is our windoze folks implement "secure updates only" in ad, so not sure how this affects things. I know I'm looking at this as in their windoze-only world, they don't even allow "foreign" win dhcp services to update client records because of the whole "best practices" thing of not having dhcp on a forest-integrated host, thus linux boxes never get hostnames registered in dns.

Mac finally broke down and supported this too as a barrier of entry to "enterprise" environments".

If it's the *user* password, you really shouldn't need it. For
NTLM-based authentication, winbind will be able to proxy it for you. Or
ideally you can use Kerberos. Although that's a little complex since the
ccache is owned by the user, not root.

If it really does have to have the *password*, then perhaps we should be
looking at a PAM module to steal it (much like gnome-keyring does).

I absolutely agree here, and ass-u-me'd it could/did/should until snooping around the keyfiles playing with pmk/okc for roaming performance and noticed that. Was like "really? we haven't figured out a better way to do this yet?". Would be nice to have it look for krb ticket presence for credentials, or at least have a pull mechanism from krb to gnome keyring to keep the pass in synch for pass changes and such.

Thanks for the comments David, very helpful!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]