SSSD / sssd

#164 Attempting to add users to group in another domain results in ambiguos error message and 0 return code
Closed: Fixed Opened by jgalipea.

Closed: Fixed
Reopen Issue

Description[[BR]]
Adding a user from one domain to a group in a different domain is not allowed. Attempting to do so results in an ambiguos message and return code of 0. It doesn't actually add the user to domain though. [[BR]]

Configuration[[BR]]

[services]
description =  Local Service Configuration
activeServices = nss, pam
reconnection_retries = 3
[services/nss]
description = NSS Responder Configuration
filterGroups = root
filterUsers = root
debug-level = 4
[services/dp]
description = Data Provider Configuration
debug-level = 4
[services/pam]
description = PAM Responder Configuration
[services/monitor]
description = Service Monitor Configuration
[domains]
description = Domains served by SSSD
domains = LOCAL,LDAP
[domains/LOCAL]
description = LOCAL Users domain
enumerate = TRUE
minId = 2000
maxId = 2010
magicPrivateGroups = TRUE
provider = local
[domains/LDAP]
description = Proxy request to our LDAP server
enumerate = TRUE
minId = 1000
maxId = 1010
cache-credentials = FALSE
provider = proxy
libName = ldap
libPath = libnss_ldap.so.2

Steps to Reproduce[[BR]]
1. install sssd with the above configuration [[BR]]
2. edit ldap.conf from your directory server settings [[BR]]
3. add a valid local sss user[[BR]]
4. attempt to add the local user to an ldap domain group[[BR]]

Version[[BR]]
sssd-2009090414-0.fc11.i586 [[BR]] [[BR]]

NOTE: same happens with provider = ldap

sorry ... error message returned : Unsupported domain type

This error message is correct. You are attempting to add a local user to the ldap domain group. The ldap domain is an unsupported domain type for the tools.

now error message is different ... "Error initializing the tools" ?? I don't think this is descriptive enough for the end user.

Fields changed

owner: somebody => jhrozek

Fields changed

milestone: SSSD 0.6.0 => SSSD 1.0

Fields changed

status: new => assigned

Fixed with 62aa4da7dc3a7826c5a942349e1af9631ca819f5

fixedin: => 0.7.0
resolution: => fixed
status: assigned => closed
tests: 0 => 1

There was a bug in the tests for these scenarios - thanks jakub - however, once fixed, uncovered a more serious issue ...
[[BR]]

When attempting to add a user in one ldap domain to a group in another ldap domain

[root@localhost ~]# sss_usermod -a Group1@BOS.REDHAT.COM puser1@EXAMPLE.COM
Aborted (core dumped)
[root@localhost ~]# echo $?
134
[root@localhost ~]# file core.28934 
core.28934: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'er1@EXAMPLE.COM'

resolution: fixed =>
status: closed => reopened

attaching core file
core.28984

version[[BR]]

sssd-0.7.0-0.2009101520git9a554bc.fc11.i586
sssd-client-0.7.0-0.2009101520git9a554bc.fc11.i586
sssd-debuginfo-0.7.0-0.2009101520git9a554bc.fc11.i586

When two ldap backends (with no local back end), the error message is "Error initializing the tools", I think it could be more descriptive to let the user know what the issue is.
Like "Error initializing the tools, No Local domain".

Comment 10 is unrelated to the original bug report. Please open a new ticket.

This ticket is being marked resolved.

resolution: => fixed
status: reopened => closed

Fields changed

tests: 1 => 0

Fields changed

rhbz: => 0

Metadata Update from @jgalipea:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.0

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1206

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.
Metadata
None
None
None
Normal
defect
SSSD
master
0
0
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.