Re: Machine authentication and dynamic dns for AD

[Michael Butash <michael butash net>]

> > 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/intel.com//}" != "$1" ]; then
>                  logger "Setting Intel reverse DNS for $HOST.$DOMAIN.corp.intel.com 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.$DOMAIN.corp.intel.com $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!

-mb