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:Joakim.Tjernlund@infinera.com]
Sent: Monday, August 22, 2016 11:10 AM
To: sssd-users(a)lists.fedorahosted.org
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/GENTOO-LABBBB(a)TRANSMODE.SE
15 RestrictedKrbHost/GENTOO-LABBBB(a)TRANSMODE.SE
15 RestrictedKrbHost/GENTOO-LABBBB(a)TRANSMODE.SE
15 RestrictedKrbHost/GENTOO-LABBBB(a)TRANSMODE.SE
15 RestrictedKrbHost/GENTOO-LABBBB(a)TRANSMODE.SE
15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se(a)TRANSMODE.SE
15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se(a)TRANSMODE.SE
15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se(a)TRANSMODE.SE
15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se(a)TRANSMODE.SE
15 RestrictedKrbHost/gentoo-labbbb.infinera.com.transmode.se(a)TRANSMODE.SE
...
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
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org