I am joining a machine on our network to our Active Directory domain as part of the AD test day. This is on an up-to-date F18 pre-beta with realmd-0.9-1.fc18 from updates-testing The command realm --verbose join --user=shoop campus.tue.nl succeeds in joining the computer to the domain. However due to our admittedly non-conventional DNS setup, the dynamic DNS registration tries to use an incorrect hostname. Background: Active Directory is responsible for it's own domain, which is campus.tue.nl. The top level tue.nl domain is served from a non-Microsoft DNS server. In addition, the campus DHCP server is also not a Microsoft implementation. So, this particular machine was registered on the DHCP server with a fixed IP / DNS name as pclin282.win.tue.nl / 131.155.68.12 This name, pclin282.win.tue.nl is set as the system hostname in /etc/sysconfig/network using HOSTNAME= . The problem is that realmd, when joining, tries to register this exact name in the AD dynamic DNS, while it should be pclin282.campus.tue.nl as AD is only responsible for this DNS subdomain. For reference, Windows clients are registered as dynamic DHCP clients in the DHCP server. They get an address that reverse resolves to, e.g. dyn068074.nbw.tue.nl When joined they then proceed to dynamically register pcNAME.campus.tue.nl in the Active Directory. Full output below: [stijn@pclin282 ~]$ realm --verbose join --user=shoop campus.tue.nl * Searching for kerberos SRV records for domain: _kerberos._udp.campus.tue.nl * Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.campus.tue.nl * campusdc5.campus.tue.nl:88 campusdc3.campus.tue.nl:88 campusdc2.campus.tue.nl:88 campusdc1.campus.tue.nl:88 campusdc4.campus.tue.nl:88 * Found kerberos DNS records for: campus.tue.nl * Found AD style DNS records for: campus.tue.nl * Successfully discovered: campus.tue.nl Password for shoop: * Couldn't find file: /usr/sbin/sss_cache * Required files not present, installing: /usr/sbin/sss_cache, /usr/sbin/sssd, /usr/bin/net * Installing: sssd-tools, sssd * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf conf setparm global realm CAMPUS.TUE.NL * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf conf setparm global kerberos method system keytab * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U shoop ads join CAMPUS.TUE.NL createcomputer=WIN/Computers/Linux/AD test day Enter shoop's password: DNS update failed: NT_STATUS_UNSUCCESSFUL Using short domain name -- TUE Joined 'PCLIN282' to realm 'campus.tue.nl' DNS Update for pclin282.win.tue.nl failed: ERROR_DNS_GSS_ERROR * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf -U shoop ads keytab create Enter shoop's password: * LANG=C /usr/bin/net -s /usr/lib64/realmd/net-ads-smb.conf conf list [global] kerberos method = system keytab workgroup = TUE security = ads realm = campus.tue.nl * /usr/bin/systemctl enable sssd.service ln -s '/usr/lib/systemd/system/sssd.service' '/etc/systemd/system/multi-user.target.wants/sssd.service' * /usr/bin/systemctl restart sssd.service Failed to issue method call: Access denied * /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir Failed to issue method call: Access denied * /usr/bin/systemctl try-restart accounts-daemon.service Failed to issue method call: Access denied ! Flushing name caches failed * Successfully enrolled machine in realm
Interesting. We need to solve host names better, possibly changing the local host name when joining an AD domain, the same way AD does on Windows.
In Fedora 19 sssd takes care of updating the domain with the right DNS host name. So I think we can mark this as fixed.
(In reply to comment #2) > In Fedora 19 sssd takes care of updating the domain with the right DNS host > name. So I think we can mark this as fixed. Just to make sure -- the SSSD would use the host name configured with ad_hostname directive, falling back to machine's host name. Does realmd configure ad_hostname with a meaningful value? It didn't on the test machine I just checked, but that was F-18... Also, the SSSD would only update the hostname after going online for the first time. So the sequence could be: * realm join -- joins the machine w/o updating the DNS entry * machine is idle and neither NSS nor PAM requests are made * the SSSD starts offline, so until the first periodical DNS refresh, there would be no update at all. This could be mitigated by the SSSD forcing the first refresh after startup (or after initial configuration?) no matter the refresh interval.
(In reply to comment #3) > This could be mitigated by the SSSD forcing the first refresh after startup > (or after initial configuration?) no matter the refresh interval. I think there needs to be a generic mechanism to tell SSSD its starting up for a domain for the first time since it was (re)configured, and to perform the various actions it needs to do at that point. For example: * DNS updates * (future) GPO machine policy pull etc.
(In reply to comment #4) > (In reply to comment #3) > > This could be mitigated by the SSSD forcing the first refresh after startup > > (or after initial configuration?) no matter the refresh interval. > > I think there needs to be a generic mechanism to tell SSSD its starting up > for a domain for the first time since it was (re)configured, and to perform > the various actions it needs to do at that point. For example: > > * DNS updates > * (future) GPO machine policy pull > etc. This is a very good idea, but a totally generic mechanism is out of scope for 1.10, I'm afraid. But I think it would make sense for DNS updates and we could squeeze that change to 1.10 very easily. So I'm going to create two upstream RFEs - one for a generic mechanism for providers to register callbacks that would be invoked if the SSSD is reconfigured and one for enabling the DNS updates after the first startup. Thank you for taking the time to brainstorm about the issue, Stef!
(In reply to comment #5) > So I'm going to create two upstream RFEs - one for a generic mechanism for > providers to register callbacks that would be invoked if the SSSD is > reconfigured https://fedorahosted.org/sssd/ticket/1925 >and one for enabling the DNS updates after the first startup. https://fedorahosted.org/sssd/ticket/1926