[Freeipa-users] Using subdomains (or dots) in hostnames

[Jakub Hrozek]

On Thu, Sep 12, 2013 at 02:54:10PM +0300, Thomas Raehalme wrote:
> Hi!
> 
> >> Let's say we're using domain example.com. Adding clients a.example.com
> >> and b.example.com was smooth. Adding client a.sub1.example.com also
> >> had no problems until I tried to get sudoers from the IPA server
> >> (using SSSD and LDAP as suggested). The client fails to find any users
> >> matching the server name. Because the only difference compared to a
> >> fully functional server is the dot in the host name, that's probably
> >> the reason why no sudoers are found for the server in the subdomain?
> >
> >What do you use in nsswitch.conf for sudoers? ldap or sss? If sss, can
> >you also paste your sssd.conf?
> 
> >Can you paste the output of sudo along with the -D parameter to get some
> >debugging?
> 
> I managed to get subdomains working after adding the subdomain to the
> IPA DNS and filling in the various SRV records pointing to the IPA
> master. After the DNS was setup properly, DNS discovery would display
> the correct subdomain on ipa-client-install.
> 
> After the DNS discovery was successful, also sudo started working
> properly on most servers. As I specified sss for sudoers in
> nsswitch.conf and added the necessary configuration to sssd.conf as
> described in the RedHat documentation, I was able to sudo the commands
> I had enabled in the IPA policy. That's great!
> 
> Some servers are still, however, causing headache. According to
> /var/log/secure sudo can authenticate me, but for some reason the list
> of allowed commands is empty (sudo -l responds "Sorry, user xxx may
> not run sudo on yyy."). I have defined sudo rules so that anybody can
> use sudo on any host, but only certain commands. I'll try to debug the
> problems and let you know how it goes.
> 
> The caching mechanism for sudo/sssd and especially clearing the cache
> with sss_cache has turned out to be somewhat challenging to
> understand. Does anybody know the correct parameters that cause the
> sudoers cache be invalidated?

Unfortunately sss_cache cannot clean sudoers rules. It's not as easy as
it sounds, I'm afraid, but we're tracking the work in:
https://fedorahosted.org/sssd/ticket/2081