I’m still working out the whole DNS aspect of Identity Management, and I think I have most of it worked out. But I have 2 file servers left to integrate and I’m having an odd time of things.
After the client install, the shared file systems all seem to be working just fine on remote systems (yay for solving my previous problem). But on the file server itself it doesn’t quite understand something, and I’m fairly certain it’s something I need to correct in DNS. I haven’t had to manage a DNS server like this before, and I’m laying this issue squarely at the feet of my manager who set things up this way in NIS+.
What I see locally for both mounted and shared file systems is that both user and groups appear in an ls -l with username@domain groupname@domain . This does not appear on any of the systems where the fileserver is mounted, and access looks like it’s working there just fine.
The oddity seems to revolve around the fact that the primary name of this server is “sherlock-hemlock”, but every mounted system just goes by the name “hemlock”. I’m certain there’s some DNS naming convention I need to apply to “sherlock-hemlock” that allows “hemlock” to just point back to it the same way. I’ve even added a CNAME of “hemlock” that points to “sherlock-hemlock”.
Not sure what I’m missing, and I could use some advice.
You probably need to add SPN’s (service principal names) for the CNAME to the machine account for the file server in your IDM domain. Most likely both for the short form (host/hemlock) and the FQDN (host/hemlock.domain.tld).
The user and group names having an @domain has zero to do with DNS. It has everything to do with how those ID’s are being resolved on the system.
It would be helpful to know how your IdM domain, your clients (including your file server) is set up. It should also be noted that combining NIS and SSSD for ID resolution will create confusing and potentially unsolvable issues.
Is AD involved here in any way ? such as freeipa, sssd or winbind ? If so, then your hostname ‘sherlock-hemlock’ is too long, there is a 15 character limit.
Yes, I’m going to go into DNS and set up the alias names for the server.
NIS is completely out of the equation with the migration to IdM. NIS services are disabled and should not be impacting this at all. This is running the same configuration for LDAP and SSS as on my other servers.
Yes, I’m using freeipa. The system name length “could” be an issue? But the problem is only happening on that system.
I’m going to try a few more things to see if I can sort through this. But for now it looks like the rest of the system, including the shared file systems, are working elsewhere. This is only going to cause issues for anyone directly accessing the file server. We’ve provided SMB access through MacOS Finder for people to directly get to their files. I need to sort out this UID / GID thing before I enable that.
The CNAME is entered and it responds with the name, then the canonical name (both correct) with the correct IP address.
Still need to run down this UID / GID issue though. It’s odd to me this is the first time seeing this.
After everything, it looks like things are working correctly, just the odd display of user and group name. Otherwise, I can sign on normally with my Kerberos ticket.
Still scratching my head over this, and I’d like to know if this is something I can easily clean up.
The users and groups showing with @domain is based on how your system is resolving names. Since sssd is what is required to connect to idm, your “problem” will start in sssd.conf.
There was a default_domain_suffix that was in the config (not in any of the others) that showed it. Once I removed it and restarted sssd service it was correct. Whew. What an oddball thing.