Red Hat Bugzilla – Bug 1293538
[RFE] Netgroup LDAP Authentication with Satellite 6.
Last modified: 2018-02-21 07:33:41 EST
>> Description of problem: Netgroup LDAP Authentication with Satellite 6. Version-Release number of selected component (if applicable): >> How reproducible: A RHEL 7.1 installation with Satellite 6.1.1 configured to use external LDAP authentication (created using hammer) # hammer auth-source ldap create --name LDAP1 --host ldap.example.org --server-type posix --tls yes --port 636 \ --base-dn ou=People,ou=example,o=org,c=au --groups-base ou=netgroup,ou=example,o=org,c=au --attr-login uid The User Group can then be created and an External Group linked to it (also using hammer)... # hammer user-group create --name Test # hammer user-group external create --auth-source-id 3 --name test-netgroup --user-group Test >> Actual results: This returns a "500 Internal Server Error" - but checking in the Web UI the external group is displayed as linked correctly. Trying to then refresh the display to show the users in the LDAP netgroup does nothing - no users are found within the group. (Creating the user group and external linking via the Web UI returns NO errors - only via hammer do we get a clue something is wrong) In the foreman production.log we see the 500 error: 2015-12-09 09:30:19 [I] Processing by Api::V2::ExternalUsergroupsController#create as JSON 2015-12-09 09:30:19 [I] Parameters: {"external_usergroup"=>{"name"=>"test-netgroup", "auth_source_id"=>"3"}, "apiv"=>"2", "usergroup-id"=>"5"} 2015-12-09 09:30:20 [W] Creating scope :completer_scope. Overwriting existing method Organization.completer_scope. 2015-12-09 09:30:20 [I] Authorized user ggatward(Geoff Gatward) 2015-12-09 09:30:20 [I] Rendered api/v2/external_usergroups/create.json.rabl (2.3ms) 2015-12-09 09:30:20 [E] Group does not have any members (RuntimeError) /opt/rh/ruby193/root/usr/share/gems/gems/ldap_fluff-0.3.2/lib/ldap_fluff/generic.rb:47:in 'users_for_gid' /opt/rh/ruby193/root/usr/share/gems/gems/ldap_fluff-0.3.2/lib/ldap_fluff/ldap_fluff.rb:35:in 'user_list' /usr/share/foreman/app/models/auth_sources/auth_source_ldap.rb:107:in 'users_in_group' /usr/share/foreman/app/models/external_usergroup.rb:33:in 'users' ... ... 2015-12-09 09:30:20 [I] Completed 500 Internal Server Error in 441ms 2015-12-09 09:30:20 [F] If we do the same setup but use a posix group from LDAP instead, everything works as expected (no 500 error and users are resolved) >> Expected results: everything works as expected (no 500 error) Additional info:
Moving 6.2 bugs out to sat-backlog.
Netgroup grouping is alternative to posix usergroups. It works differently, they are to be found at ou=Netgroup,dc=example,dc=com tree with cn as their name. For association with user, attribute nisNetgroupTriple is defined in this object. Attribute is defined multiple times for each user in a given netgroup. The structure is triple ($server, $user, $domain). While users can set group base DN today, we hardcode "memberuid" that we use for searching posix groups. We could make this also configurable per LDAP auth source and let ldap_fluff search in this triple. I'm cancelling the need info as it's not clear what was asked.
Created redmine issue http://projects.theforeman.org/issues/16112 from this bug
Upstream bug assigned to tstrachota@redhat.com
Hello, Any update on this bug ?
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/16112 has been resolved.
Build:Satellite 6.3.0 snap33 I am unable to associate external netgroup to user groups in Satellite Unable to save Could not refresh external usergroups: NoMethodError - undefined method `nisnetgrouptriple' for #<Net::LDAP::Entry:0x007fde55144638> - The netgroup is created in IPA [root@qe-sat6-ipa ~]# ipa netgroup-show netgroup1 Netgroup name: netgroup1 NIS domain name: <domain> Member User: netgroup_user Member Host: qe-sat6-feature-rhel6.<domain> [root@qe-sat6-ipa ~]# ldapsearch -LLL -x -b 'cn=netgroup1,cn=ng,cn=compat,dc=satqe,dc=lab,dc=eng,dc=rdu2,dc=redhat,dc=com' dn: cn=netgroup1,cn=ng,cn=compat,<domain> objectClass: nisNetgroup objectClass: top nisNetgroupTriple: (qe-sat6-feature-rhel6.<domain>,netgro up_user,<domain>) cn: netgroup1
Update: Even when there is error on submitting the usergroup with external netgroup. The netgroup is associated with usergroup On trying to login into satellite using netgroup user. The user doesn't inherit permissions roles from user group. Id: 5 Login: netgroup_user Name: foreman_proxy user Email: netgroup_user@<domain> Admin: no Last login: 2018/01/23 08:11:58 Authorized by: IDM Effective admin: no Locale: default Timezone: default Description: Default organization: Default location: Roles: User groups: Inherited User groups: Locations: Default Location Organizations: Default Organization Created at: 2018/01/23 08:11:57 Updated at: 2018/01/23 08:11:57
Sanket, could you share the backtrace from the server logs when this error occurs, please?
Thanks mhulan, once again Looks like I had wrong groupDn configured. On updating the correct groupdn I was able to a associate the netgroup successfully Also, the netgroup inherted the user group [root@qe-capsule-feature-rhel6 ~]# hammer user info --id 7 Id: 7 Login: netgroup_user Name: foreman_proxy user Email: netgroup_user@<domain> Admin: no Last login: 2018/01/23 12:19:39 Authorized by: IDM Effective admin: no Locale: default Timezone: default Description: Default organization: Default location: Roles: User groups: 1) Usergroup: idm Roles: Create ARF report Compliance viewer Compliance manager Inherited User groups: Locations: Default Location Organizations: Default Organization Created at: 2018/01/23 12:19:39 Updated at: 2018/01/23 12:19:39
I'm glad it got resolved. It seems like we should file a new BZ about how we report such configuration errors. A message with some hint would be more useful. Sanket, since you know what was configured wrong, may I ask you to file one?
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0336