I'm joining RHEL to Active Directory and have had success updating DDNS using
the following (CASE indicates the case the entry is in) 'dnsdomain' here is
the domain name of my AD, ad.corp.com, and FQDNs of hosts joined to that AD
look like this host.ad.corp.com. I'm not cross joining, but do have alternate
domains in Kerberos. That way any host that has a dns domain different from AD
it still works. Eg otherdnsdomain is other.corp.com, and the host fqdn could
be host.other.corp.com. dynamic DNS doesn't exist in the other.corp.com
namespace, so DDNS doesn’t work there, naturally, only AD DDNS.
On RHEL 7
~# hostnamectl set-hostname <fqdn>
Resolv.conf
Domain <dnsdomain>
Search <dnsdomain>
Krb5.conf
[libdefaults]
default_realm = <DNSDOMAIN>
dns_lookup_realm = false
dns_lookup_kdc = false
forwardable = true
ticket_lifetime = 24h
renew_lifetime = 7d
[realms]
<DNSDOMAIN> = {
kdc = <dnsdomain>
admin_server = <dnsdomain>
}
[domain_realm]
.<dnsdomain>=<DNSDOMAIN>
<dnsdomain>=<DNSDOMAIN>
.<otherdnsdomain>=<DNSDOMAIN>
<otherdnsdomain>=<DNSDOMAIN>
~# adcli join --domain=DNSDOMAIN --login-user=my-user --verbose
--service-name=host --service-name=RestrictedKrbHost --show-details
Show details on adcli shows you quite a bit, which is nice, domain controllers,
what names it's using for fully qualified, domain name, computer account name,
domain realm... it may help.
With that I get a keytab like this
# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
3 HOST$@DNSDOMAIN
3 HOST$@DNSDOMAIN
3 HOST$@DNSDOMAIN
3 HOST$@DNSDOMAIN
3 HOST$@DNSDOMAIN
3 host/HOST@DNSDOMAIN
3 host/HOST@DNSDOMAIN
3 host/HOST@DNSDOMAIN
3 host/HOST@DNSDOMAIN
3 host/HOST@DNSDOMAIN
3 host/fqdn@DNSDOMAIN
3 host/fqdn@DNSDOMAIN
3 host/fqdn@DNSDOMAIN
3 host/fqdn@DNSDOMAIN
3 host/fqdn@DNSDOMAIN
3 RestrictedKrbHost/HOST@DNSDOMAIN
3 RestrictedKrbHost/HOST@DNSDOMAIN
3 RestrictedKrbHost/HOST@DNSDOMAIN
3 RestrictedKrbHost/HOST@DNSDOMAIN
3 RestrictedKrbHost/HOST@DNSDOMAIN
3 RestrictedKrbHost/fqdn@DNSDOMAIN
3 RestrictedKrbHost/fqdn@DNSDOMAIN
3 RestrictedKrbHost/fqdn@DNSDOMAIN
3 RestrictedKrbHost/fqdn@DNSDOMAIN
3 RestrictedKrbHost/fqdn@DNSDOMAIN
For my SPNs. That matches the computer object in AD.
In my process I do invoke kinit -k HOST$ to get a Kerberos ticket for the
computer. Newer versions of adcli added support for keeping that ticket up to
date, it used to expire. SSSD uses that to auth to AD DNS up update its DNS
record. I'm even going to use that ticket to update a confidential attribute
on the computer object to change and store the root user password on the object
in AD, the same way Windows computers use LAPS for local admin account
credentials. https://www.microsoft.com/en-us/download/details.aspx?id=46899
instead of a client side GPO to manage time frames and whatnot, it will be a
puppet module. I digress, point being once you have the computer Kerberos
ticket, you can do other stuff, not just DDNS.
It all seems to work alright for me.
Todd
-----Original Message-----
From: Joakim Tjernlund [mailto:[email protected]]
Sent: Monday, August 22, 2016 11:10 AM
To: [email protected]
Subject: [SSSD-users] Re: DDNS not working due to non FQDN hostname
On Mon, 2016-08-22 at 12:46 +0200, Joakim Tjernlund wrote:
> On Mon, 2016-08-22 at 12:06 +0200, Petr Spacek wrote:
> >
> > On 22.8.2016 11:18, Joakim Tjernlund wrote:
> > >
> > >
> > > On Mon, 2016-08-22 at 11:13 +0200, Petr Spacek wrote:
> > > >
> > > >
> > > > On 22.8.2016 10:49, Ondrej Valousek wrote:
> > > > >
> > > > >
> > > > >
> > > > > I do not think this is a good patch - systematically.
> > > > > Maybe better approach is to rather use gethostbyname() than
> > > > > gethostname().
> > > > > My 2 cents.
> > > >
> > > > Most importantly, this will work only for the simplest possible
> > > > case where host name of the client is sub-domain of AD domain.
> > > >
> > > > It will break e.g. in this scenario:
> > > > AD domain = example.net.
> > > > Client's hostname = myclient.branch1.example.net.
> > >
> > > No, the patch will not touch hostname if it already have a "." in it.
> >
> > Yes, but it means that we are back to to manual configuration. Even
> > worse, if your client *is supposed* to have name
> > "myclient.branch1.example.net." but you did not configure it
> > explicitly, it will create DNS records for incorrect name
> > "myclient.example.net.".
>
> Sure, I just figured we should at least try to fix the common case.
> As is, it is always broken(No DNS records at all)
>
> Anyhow, I will try a FQDN hostname here and see what happens ...
>
Well, that did not workout quite as I had hoped:
if hostname=gentoo-labbbb.infinera.com and I join(adcli) to other
domain(transmode.se) I get:
....
15 RestrictedKrbHost/[email protected]
15 RestrictedKrbHost/[email protected]
15 RestrictedKrbHost/[email protected]
15 RestrictedKrbHost/[email protected]
15 RestrictedKrbHost/[email protected]
15 RestrictedKrbHost/[email protected]
15 RestrictedKrbHost/[email protected]
15 RestrictedKrbHost/[email protected]
15 RestrictedKrbHost/[email protected]
15 RestrictedKrbHost/[email protected]
...
Notice the double domain? These are from adcli --service-name=RestrictedKrbHost
DNSDOMAIN="transmode.se"
REALM="TRANSMODE.SE"
HOSTNAME=gentoo-labbbb
adcli -v join -D "${DNSDOMAIN}" "${DNSDOMAIN}"
--host-fqdn="${HOSTNAME}"."${DNSDOMAIN}" --service-name="nfs"
--service-name="RestrictedKrbHost" --service-name="cifs"
--user-principal="host/${H OSTNAME}.${DNSDOMAIN}@${REALM}"
Any ideas?
Jocke
_______________________________________________
sssd-users mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
_______________________________________________
sssd-users mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
