On Tuesday, 4 June 2019 21:23:03 ACST Thorsten Kukuk wrote:
On Tue, Jun 04, Rodney Baker wrote:
On Monday, 3 June 2019 21:20:55 ACST Thorsten Kukuk wrote:
/etc/passwd, /etc/group and /etc/shadow: This is the big, open problem. We looked at many possible solutions, but didn't found the real, generic one.
Or perhaps it is time to consider a roadmap to deprecating these altogether and moving to an LDAP-based solution? Or is that a bridge too far?
There is one important thing to remember: this has to work even if the rest of the system fails (so rescue system, initrd rescue shell, ...). Most of the time in this scenarios, LDAP will not work, too.
Yes, good point. LDAP isn't necessarily the right answer, however in these cases only the root user absolutely needs to be able to login. A rescue system or initrd rescue shell could manage that separately (or in parallel) to the normal AAA mechanism. Whatever solution is eventually adopted will certainly need to take those cases into account in the design and implementation.
And having a local LDAP daemon for system accounts running on every system and a second one for the normal users somewhere else in the network: will this really simplify the setup and make it more robust?
In this case, I'd see the remote LDAP server would take precedence over the local, with the local being for fallback; however, I concede that this would be less than optimal. I take your point about system accounts - I spend too much time at work dealing with M$ and AD so I tend to think mainly about user authentication/authorisation/accounting, forgetting about system services.
Somebody had the idea if it wouldn't be possible to write a sssd plugin to merge this files, no idea if this is feasible.
Setting sssd rules to apply policies from the primary server, and use local as fallback should be possible, in theory, but I don't know enough about sssd internals to be sure.
There were also ideas to throw away /etc/passwd, /etc/group, ... and invent something completly new. If somebody has ideas for this and time, fine. But we should make that independent of this discussion, to not make it too complex and block ourself.
Thorsten
Agreed. I only mentioned it because of the comment about pam-related files being an "open problem". I'll drop it now. :) -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================