4 Jun
2019
4 Jun
'19
3:20 p.m.
On Tuesday, 4 June 2019 21:23:03 ACST Thorsten Kukuk wrote:
On Tue, Jun 04, Rodney Baker wrote:
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.
On Monday, 3 June 2019 21:20:55 ACST Thorsten
Kukuk wrote:
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. /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?
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(a)iinet.net.au
CCNA #CSCO12880208
==============================================================