7:15 a.m.
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.
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?
Cheers,
mathias
7:22 a.m.
On 02/11/15 13:15, 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.
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))*))
Hi, never mind the root user, is that a search filter that sssd is
using? it seems to search for a specific user and all users at the same
time.
Rowland
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?
Cheers,
mathias
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
7:42 a.m.
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
7:47 a.m.
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...
Cheers,
mathias
2015-11-02 14:42 GMT+01:00 Sumit Bose <sbose(a)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(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
9:19 a.m.
Security wise this is a horrible idea. If you have uid 0 you are effectively root. There
should only be one root for any Linux system. This is what sudo is made for. If you really
think you need to run as root sudo bash or something. Not that I’m recommending that, but
it’s at least better than having a bunch of accounts with root access on your servers.
From: sssd-users-bounces(a)lists.fedorahosted.org
[mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of mathias dufresne
Sent: Monday, November 02, 2015 7:16 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
Subject: [SSSD-users] SSSD and accounts with UID = 0
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.
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?
Cheers,
mathias
9:35 a.m.
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(a)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(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
8:42 a.m.
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(a)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(a)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(a)lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> >
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> >
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
9:34 a.m.
On Wed, Nov 04, 2015 at 03:42:14PM +0100, mathias dufresne wrote:
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 : )
If you want to look the sysadmins over the shoulder the project Nikolai
is working on might be interesting to you
http://spbnick.github.io/2015/10/26/open-source-session-recording.html
bye,
Sumit
2015-11-02 16:35 GMT+01:00 Sumit Bose <sbose(a)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(a)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(a)lists.fedorahosted.org
> > > > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> > >
> > > _______________________________________________
> > > sssd-users mailing list
> > > sssd-users(a)lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> > >
>
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
3098
days inactive
3100
days old
sssd-users@lists.fedorahosted.org
8 comments
5 participants
participants (5)
-
John Hodrien -
mathias dufresne -
Rowland Penny -
Sumit Bose -
Thackeray, Neil L