Why I like the idea of several root accounts is because generally there are several sysadmins for the same system. And sysadmins often use root account, so there is no possibility to tell who made the mistake when one was performed.
Sudo would be nice if there was a simple way to configure it to refuse shells as root. Sudo is great as each command is logged... as long as the user don't get a shell (everywhere, even in vi, awk....)

With nominative root accounts sysadmins get a shell as root directly. Of course they can modify their own history in case of mistake but something should exist to log all commands ran by current user. Yep the whole idea is to trace sysadmins mistakes : )

2015-11-02 16:35 GMT+01:00 Sumit Bose <sbose@redhat.com>:
On Mon, Nov 02, 2015 at 02:47:58PM +0100, mathias dufresne wrote:
> Thank you Sumit for that clear answer.
>
> Does this restriction applies also so to AD provider? In AD aren't all
> connections encrypted and authenticated through Kerberos? That question
> could be quiet naive...

You are right, in an AD environment Kerberos is used to provide mutual
authentication between client and server. Nevertheless user with UID 0
are not supported here as well.

bye,
Sumit

>
> Cheers,
>
> mathias
>
> 2015-11-02 14:42 GMT+01:00 Sumit Bose <sbose@redhat.com>:
>
> > On Mon, Nov 02, 2015 at 02:15:30PM +0100, mathias dufresne wrote:
> > > Hi all,
> > >
> > > I'm trying to define in my AD administrative accounts for Linux boxes. To
> > > do that I initially thought to create nominative account with some suffix
> > > (ex: <username>_adm) and give them UID=0 to make them root accounts.
> > >
> > > As SSSD comes with filtering option to avoid some users or groups can
> > > connect on some given system using SSSD, I would have added these users
> > to
> > > some groups and finally grant access to one admins group to a first bunch
> > > of systems, the secodn admins group to a second bunch of systems, etc...
> > >
> > > Reading doc and man pages about SSSD sometimes it seems to say that is
> > > possible to have users retrieved by SSSD when they have UID = 0,
> > sometimes
> > > it says it is not possible.
> > >
> > > For example: man sssd.conf on Centos 7 (sssd 1.12.2
> > > - 1.12.2-58.el7_1.17.x86_64) gives:
> > > pam_trusted_users (string)
> > >            Specifies the comma-separated list of UID values or user names
> > > that are allowed to access
> > >            the PAM responder. User names are resolved to UIDs at startup.
> > >
> > >            Default: all (All users are allowed to access the PAM
> > responder)
> > >
> > >           * Please note that UID 0 is always allowed to access the PAM
> > > responder even in case it is*
> > > *           not in the pam_trusted_users list.*
> > >
> > > As man pages says users with "UID 0 is always allowed..." I would
> > expected
> > > this refers users retrieved by SSSD, so that SSSD accept to retrieve
> > users
> > > with UID=0.
> >
> > What comes after allowed is important "UID 0 is always allowed to access
> > the PAM responder". The SSSD responders are interfaces to local services
> > running on the same host as SSSD. For some of the services one might
> > want to restrict access. E.g. since the PAM responder handles user
> > passwords and authentication in some environments it might be useful to
> > only allow specific local users to access the PAM responder. The comment
> > in the man page should underline that independent of the configures
> > restrictions root (UID 0) is always allowed to access the responder.
> > This is completely unrelated to the user and UIDs read from a remote
> > server.
> >
> > >
> > > Unfortunately even adding "min_id = 0" in my sssd.conf SSSD refuse to
> > show
> > > uid=0 users.
> > >
> > > In SSSD logs I have ldapserach filter shown as follow:
> > >
> > (&(cn=<username>)(objectclass=user)(cn=*)(&(uidNumber=*)*(!(uidNumber=0))*))
> > >
> > > And somewhere I read this is by design that now SSSD refuses to allow
> > users
> > > with UID=0.
> > >
> > > As all that is not too clear for me, where are we now, are users with
> > UID=0
> > > allowed or not?
> >
> > No, they are not. SSSD explicitly does not return a user with UID==0.
> > The risk here would be too high that this gets exploited. E.g. typically
> > the user entry with the UID is read from an LDAP server. To be
> > compatible with many existing LDAP setups SSSD does not force SSL/TLS on
> > the connection which reads the user entry. So SSSD cannot reliable
> > determine if it talks to the "real" LDAP server or a fake one prepared
> > by an attacker.
> >
> > HTH
> >
> > bye,
> > Sumit
> > >
> > > Cheers,
> > >
> > > mathias
> >
> > > _______________________________________________
> > > sssd-users mailing list
> > > sssd-users@lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> >
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users@lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> >

> _______________________________________________
> sssd-users mailing list
> sssd-users@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users