Hello,
I'm trying to include a user "local" defined in /etc/passwd in a ldap group called "test" by adding a memberUid in the group definition.
With the getent command I see the change:
getent group test
test:*:3000:local
However when I run the id command for user local the group test is not shown. Only the locally defined group "local" is listed. Also accessing resources which require membership to group test fails.
id local
uid=1000(local) gid=1000(local) groups=1000(local)
I don't have this issue with users defined on the ldap server (the id command lists all the groups they are members of). The behavior is the same with sssd 1.11.6 on CentOS 6.6 and sssd 1.9.2 on Centos 6.5.
On different machines (Centos 5.x and DebianWheezy) the local user shows up with the correct ldap groups, but those systems don't use sssd to bind to the ldap server.
The version of the server is OpenLDAP 2.4.31
Is there anything in the configuration file which would enabled this behavior with sssd? Any help is appreciated.
--Tavi
Is this a known issue? Does anybody have a solution for this?
Thanks, --Tavi
On Thu, Nov 20, 2014 at 4:13 PM, Octavian Afilipoai oafilipoai@gmail.com wrote:
Hello,
I'm trying to include a user "local" defined in /etc/passwd in a ldap group called "test" by adding a memberUid in the group definition.
With the getent command I see the change:
getent group test
test:*:3000:local
However when I run the id command for user local the group test is not shown. Only the locally defined group "local" is listed. Also accessing resources which require membership to group test fails.
id local
uid=1000(local) gid=1000(local) groups=1000(local)
I don't have this issue with users defined on the ldap server (the id command lists all the groups they are members of). The behavior is the same with sssd 1.11.6 on CentOS 6.6 and sssd 1.9.2 on Centos 6.5.
On different machines (Centos 5.x and DebianWheezy) the local user shows up with the correct ldap groups, but those systems don't use sssd to bind to the ldap server.
The version of the server is OpenLDAP 2.4.31
Is there anything in the configuration file which would enabled this behavior with sssd? Any help is appreciated.
--Tavi
On 11/26/2014 12:37 PM, Octavian Afilipoai wrote:
Is this a known issue? Does anybody have a solution for this?
I thought there was a ticket about this in SSSD but I can't find it. I vaguely remember that there was something couple years ago.
What is your server schema? 2307? Or 2307bis? How do you configure SSSD?
Thanks, --Tavi
On Thu, Nov 20, 2014 at 4:13 PM, Octavian Afilipoai <oafilipoai@gmail.com mailto:oafilipoai@gmail.com> wrote:
Hello, I'm trying to include a user "local" defined in /etc/passwd in a ldap group called "test" by adding a memberUid in the group definition. With the getent command I see the change: >getent group test test:*:3000:local However when I run the id command for user local the group test is not shown. Only the locally defined group "local" is listed. Also accessing resources which require membership to group test fails. >id local uid=1000(local) gid=1000(local) groups=1000(local) I don't have this issue with users defined on the ldap server (the id command lists all the groups they are members of). The behavior is the same with sssd 1.11.6 on CentOS 6.6 and sssd 1.9.2 on Centos 6.5. On different machines (Centos 5.x and DebianWheezy) the local user shows up with the correct ldap groups, but those systems don't use sssd to bind to the ldap server. The version of the server is OpenLDAP 2.4.31 Is there anything in the configuration file which would enabled this behavior with sssd? Any help is appreciated. --Tavi
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I'm using the 2307 schema on the server. The sssd config is fairly straightforward:
[domain/default] #cache_credentials = True ldap_search_base = dc=myexample,dc=com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://server_url/ tls_reqcert = demand ldap_tls_cacertdir = /etc/openldap/cacerts ldap_default_bind_dn = xxxxxxx ldap_default_authtok_type = password ldap_default_authtok = xxxxxxx
[sssd] services = nss, pam config_file_version = 2
domains = default
[nss] #filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
I found this ticket which reports a similar problem, but, according to the comments it should be fixed for one of the versions I'm using (1.11.6): https://fedorahosted.org/sssd/ticket/1020
Thanks for the help, --Tavi
On Wed, Nov 26, 2014 at 11:35 AM, Dmitri Pal dpal@redhat.com wrote:
On 11/26/2014 12:37 PM, Octavian Afilipoai wrote:
Is this a known issue? Does anybody have a solution for this?
I thought there was a ticket about this in SSSD but I can't find it. I vaguely remember that there was something couple years ago.
What is your server schema? 2307? Or 2307bis? How do you configure SSSD?
Thanks, --Tavi
On Thu, Nov 20, 2014 at 4:13 PM, Octavian Afilipoai oafilipoai@gmail.com wrote:
Hello,
I'm trying to include a user "local" defined in /etc/passwd in a ldap group called "test" by adding a memberUid in the group definition.
With the getent command I see the change:
getent group test
test:*:3000:local
However when I run the id command for user local the group test is not shown. Only the locally defined group "local" is listed. Also accessing resources which require membership to group test fails.
id local
uid=1000(local) gid=1000(local) groups=1000(local)
I don't have this issue with users defined on the ldap server (the id command lists all the groups they are members of). The behavior is the same with sssd 1.11.6 on CentOS 6.6 and sssd 1.9.2 on Centos 6.5.
On different machines (Centos 5.x and DebianWheezy) the local user shows up with the correct ldap groups, but those systems don't use sssd to bind to the ldap server.
The version of the server is OpenLDAP 2.4.31
Is there anything in the configuration file which would enabled this behavior with sssd? Any help is appreciated.
--Tavi
sssd-users mailing listsssd-users@lists.fedorahosted.orghttps://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Thank you, Dmitri Pal
Sr. Engineering Manager IdM portfolio Red Hat, Inc.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, Dec 01, 2014 at 10:00:59AM -0800, Octavian Afilipoai wrote:
I'm using the 2307 schema on the server. The sssd config is fairly straightforward:
[domain/default] #cache_credentials = True ldap_search_base = dc=myexample,dc=com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://server_url/ tls_reqcert = demand ldap_tls_cacertdir = /etc/openldap/cacerts ldap_default_bind_dn = xxxxxxx ldap_default_authtok_type = password ldap_default_authtok = xxxxxxx
[sssd] services = nss, pam config_file_version = 2
domains = default
[nss] #filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
I found this ticket which reports a similar problem, but, according to the comments it should be fixed for one of the versions I'm using (1.11.6): https://fedorahosted.org/sssd/ticket/1020
Sorry it took me so long to reply. Does the functionality work if you add: ldap_rfc2307_fallback_to_local_users = True
to the [domain/default] section and restart the SSSD ?
Yes, with this configuration option the functionality works as expected.
Thanks, --Tavi
On Tue, Dec 2, 2014 at 7:38 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Mon, Dec 01, 2014 at 10:00:59AM -0800, Octavian Afilipoai wrote:
I'm using the 2307 schema on the server. The sssd config is fairly straightforward:
[domain/default] #cache_credentials = True ldap_search_base = dc=myexample,dc=com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://server_url/ tls_reqcert = demand ldap_tls_cacertdir = /etc/openldap/cacerts ldap_default_bind_dn = xxxxxxx ldap_default_authtok_type = password ldap_default_authtok = xxxxxxx
[sssd] services = nss, pam config_file_version = 2
domains = default
[nss] #filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
I found this ticket which reports a similar problem, but, according to
the
comments it should be fixed for one of the versions I'm using (1.11.6): https://fedorahosted.org/sssd/ticket/1020
Sorry it took me so long to reply. Does the functionality work if you add: ldap_rfc2307_fallback_to_local_users = True
to the [domain/default] section and restart the SSSD ?
The workaround does not seem to work for the root user. I added the root user to the sysadm group and put the following line in the [nss] section of sssd.conf:
filter_users = ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
After restarting sssd the sysadm group does not show up for the root user. This functionality works fine for another local user. Is there additional configuration needed to enable this for the root user?
Thanks, --Tavi
On Tue, Dec 02, 2014 at 01:11:55PM -0800, Octavian Afilipoai wrote:
The workaround does not seem to work for the root user. I added the root user to the sysadm group and put the following line in the [nss] section of sssd.conf:
That's very much expected, SSSD doesn't handle the root user by design.
btw root bypasses all restrictions in Linux, why do you need root to be a member of a group?
I have root ssh logins disabled by default, and I was using this (root user in an ldap group with ssh access) as a quick way of enabling root to login via ssh on a temporary basis.
On Tue, Dec 2, 2014 at 1:17 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Tue, Dec 02, 2014 at 01:11:55PM -0800, Octavian Afilipoai wrote:
The workaround does not seem to work for the root user. I added the root user to the sysadm group and put the following line in the [nss] section
of
sssd.conf:
That's very much expected, SSSD doesn't handle the root user by design.
btw root bypasses all restrictions in Linux, why do you need root to be a member of a group?
On Tue, Dec 02, 2014 at 01:28:53PM -0800, Octavian Afilipoai wrote:
I have root ssh logins disabled by default, and I was using this (root user in an ldap group with ssh access) as a quick way of enabling root to login via ssh on a temporary basis.
Isn't it better to enable sudo from the ldap group, then?
On Tue, Dec 2, 2014 at 1:17 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Tue, Dec 02, 2014 at 01:11:55PM -0800, Octavian Afilipoai wrote:
The workaround does not seem to work for the root user. I added the root user to the sysadm group and put the following line in the [nss] section
of
sssd.conf:
That's very much expected, SSSD doesn't handle the root user by design.
btw root bypasses all restrictions in Linux, why do you need root to be a member of a group?
On Tue, Dec 2, 2014 at 1:33 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Tue, Dec 02, 2014 at 01:28:53PM -0800, Octavian Afilipoai wrote:
I have root ssh logins disabled by default, and I was using this (root user in an ldap group with ssh access) as a quick way of enabling root to login via ssh on a temporary basis.
Isn't it better to enable sudo from the ldap group, then?
That was the other option. Though, I've had some issues with sudo requiring a tty when invoked from a ssh command (ssh user@host "sudo ..."). I'll see if I can find a solution for that.
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Octavian Afilipoai