Bug 1436733
Summary: | Support non-POSIX setups | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Jakub Hrozek <jhrozek> | ||||
Component: | mod_lookup_identity | Assignee: | Jan Pazdziora <jpazdziora> | ||||
Status: | CLOSED ERRATA | QA Contact: | Scott Poore <spoore> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 7.4 | CC: | jhrozek, jpazdziora, ksiddiqu, mkosek, nsoman | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | mod_lookup_identity-1.0.0-1.el7 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2017-08-01 22:55:28 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1425891 | ||||||
Attachments: |
|
Description
Jakub Hrozek
2017-03-28 14:09:47 UTC
(In reply to Jakub Hrozek from comment #0) > > Steps to Reproduce: > 1. Define a non-POSIX SSSD domain, like this: > [domain/myappdomain] > id_provider=ldap > ...other domain specific settings.. > domain_type = application That non-POSIX SSSD domain, is it simple domain where some (?) entries will not have POSIX attributes, or is it somehow special, like that id_provider has to be ldap (instead of ipa)? > 2. Add data to the LDAP/IPA/AD server that do not carry POSIX attributes. > For example, a user and a group can be defined as: > dn: uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test > displayName: new user > uid: nonposix > krbCanonicalName: nonposix > objectClass: person > objectClass: top > objectClass: inetorgperson > objectClass: organizationalperson > objectClass: inetuser > objectClass: mepOriginEntry > initials: nu > sn: user > mail: nonposix > givenName: new > cn: new user Running ldapadd with this input, I get adding new entry "uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test" ldap_add: Object class violation (65) additional info: attribute "krbCanonicalName" not allowed (In reply to Jan Pazdziora from comment #4) > (In reply to Jakub Hrozek from comment #0) > > > > Steps to Reproduce: > > 1. Define a non-POSIX SSSD domain, like this: > > [domain/myappdomain] > > id_provider=ldap > > ...other domain specific settings.. > > domain_type = application > > That non-POSIX SSSD domain, is it simple domain where some (?) entries will > not have POSIX attributes, or is it somehow special, like that id_provider > has to be ldap (instead of ipa)? > The id provider does not matter, as long as you're confined to the joined domain. Trusted domains are not supported at the moment: https://pagure.io/SSSD/sssd/issue/3357 In general, since the use-case is about deprecating native LDAP connectors a third-party application might have, I strongly suspect that id_provider=ldap is what's going to be tested most. That said, I also tested id_provider=ipa and Sumit tested id_provider=ad during patch review. > > 2. Add data to the LDAP/IPA/AD server that do not carry POSIX attributes. > > For example, a user and a group can be defined as: > > dn: uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test > > displayName: new user > > uid: nonposix > > krbCanonicalName: nonposix > > objectClass: person > > objectClass: top > > objectClass: inetorgperson > > objectClass: organizationalperson > > objectClass: inetuser > > objectClass: mepOriginEntry > > initials: nu > > sn: user > > mail: nonposix > > givenName: new > > cn: new user > > Running ldapadd with this input, I get > > adding new entry "uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test" > ldap_add: Object class violation (65) > additional info: attribute "krbCanonicalName" not allowed Oops, I tried to sanitize the LDIF too much. Try this one: ---------- cat nonposix.ldif dn: uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test displayName: new user uid: nonposix objectClass: person objectClass: top objectClass: inetorgperson objectClass: organizationalperson objectClass: inetuser objectClass: mepOriginEntry initials: nu sn: user mail: nonposix givenName: new cn: new user ---------- It seemed to work for me: ldapadd -H ldap://unidirect.ipa.test -D'cn=Directory Manager' -wblablabla < nonposix.ldif adding new entry "uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test" Except then a bind DN must be used (also on the client that is supposed to read the entry): ldapsearch -x -H ldap://unidirect.ipa.test -b uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test -D'cn=Directory Manager' -wblablabla -s base # extended LDIF # # LDAPv3 # base <uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # nonposix, users, accounts, ipa.test dn: uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test displayName: new user uid: nonposix objectClass: person objectClass: top objectClass: inetorgperson objectClass: organizationalperson objectClass: inetuser objectClass: mepOriginEntry initials: nu sn: user mail: nonposix givenName: new cn: new user # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Because anonymous bind wouldn't be permitted to read it: ldapsearch -x -H ldap://unidirect.ipa.test -b uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test -s base # extended LDIF # # LDAPv3 # base <uid=nonposix,cn=users,cn=accounts,dc=ipa,dc=test> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 But I hope this is not a blocker for testing. To verify both the PAM and IfP operation that bug 1425891 suggests should be working, I tried to use my standard tests, with normal IPA user created with ipa user-add, and then I strip it off the POSIX attributes with changetype: modify delete: loginshell - delete: gecos - delete: homeDirectory - delete: uidNumber - delete: gidNumber - delete: objectClass objectClass: posixaccount As a result, neither id bob$$ nor ipa user-find bob$$ do not find the user so I hope it's setting up roughly the equivalent of your LDIF-created object. However, for this non-POSIX user, dbus-send lookup for org.freedesktop.sssd.infopipe.GetUserAttr string:bob$$ array:string:mail or org.freedesktop.sssd.infopipe.GetUserGroups string:bob$$ do not work either. Should they work? (In reply to Jan Pazdziora from comment #6) > > org.freedesktop.sssd.infopipe.GetUserAttr string:bob$$ array:string:mail > > or > > org.freedesktop.sssd.infopipe.GetUserGroups string:bob$$ > > do not work either. Should they work? Where my rather vaguely described "do not work" behaviour is manifested with Error org.freedesktop.DBus.Error.Failed: No such user Yes, they should. Could you give me access to your test or the environment so I can test that locally? (In reply to Jan Pazdziora from comment #6) > > As a result, neither id bob$$ nor ipa user-find bob$$ do not find the user As a result, neither id bob$$ nor ipa user-find bob$$ find the user. Sorry for the confusion. Upstream release 1.0.0 includes the change. Jan, So can I test this with IPA and just stripping off the POSIX attributes like you mentioned in comment #6? I tried with this: [root@vm2 ~]# ipa user-add nonposix --first=non --last=posix --password Password: Enter Password again to verify: --------------------- Added user "nonposix" --------------------- User login: nonposix First name: non Last name: posix Full name: non posix Display name: non posix Initials: np Home directory: /home/nonposix GECOS: non posix Login shell: /bin/sh Principal name: nonposix Principal alias: nonposix Email address: nonposix UID: 1607600003 GID: 1607600003 Password: True Member of groups: ipausers Kerberos keys available: True [root@vm2 ~]# kinit nonposix Password for nonposix: Password expired. You must change it now. Enter new password: Enter it again: [root@vm2 ~]# ldapmodify -H ldap://master.testrelm.test -D "cn=Directory Manager" -w Secret123 -f strip.ldif modifying entry "uid=nonposix,cn=users,cn=accounts,dc=testrelm,dc=test" [root@vm2 ~]# cat strip.ldif dn: uid=nonposix,cn=users,cn=accounts,dc=testrelm,dc=test changetype: modify delete: loginshell - delete: gecos - delete: homeDirectory - delete: uidNumber - delete: gidNumber - delete: objectClass objectClass: posixaccount [root@vm2 ~]# id nonposix id: nonposix: no such user [root@vm2 ~]# cat /etc/sssd/sssd.conf [domain/testrelm.test] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = testrelm.test id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client.testrelm.test chpass_provider = ipa ipa_server = _srv_, master.testrelm.test ldap_tls_cacert = /etc/ipa/ca.crt ldap_user_extra_attrs = mail, firstname:givenname, lastname:sn [sssd] services = nss, sudo, pam, ssh, ifp domains = testrelm.test [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] allowed_uids = apache, root user_attributes = +mail, +firstname, +lastname, +gidNumber, +uidNumber [secrets] [root@vm2 ~]# cat /etc/httpd/conf.d/app1.conf LoadModule authnz_pam_module modules/mod_authnz_pam.so LoadModule lookup_identity_module modules/mod_lookup_identity.so <Location /app1> AuthType Basic AuthName "private area" AuthBasicProvider PAM AuthPAMService app1 Require valid-user ErrorDocument 401 'FAIL' LookupUserAttr mail REMOTE_USER_EMAIL " " LookupUserAttr firstname REMOTE_USER_FIRSTNAME LookupUserAttr lastname REMOTE_USER_LASTNAME LookupUserAttr gidNumber REMOTE_USER_GID LookupUserAttr uidNumber REMOTE_USER_UID LookupUserGroups REMOTE_USER_GROUPS ":" LookupUserGroupsIter REMOTE_USER_GROUPS LookupUserGroups REMOTE_USER_GROUPS ":" LookupUserGroupsIter REMOTE_USER_GROUPS </Location> <Directory /var/www/html/app1> Options +Includes AddType text/html .shtml AddOutputFilter INCLUDES .shtml </Directory> [root@vm2 ~]# curl -u nonposix:Secret1234 http://$(hostname)/app1/index.shtml FAIL FYI, if I run curl with bob:Secret123 (valid IPA user/pass), it does work. So, can I test mod_lookup_identity with IPA or do I need to setup a separate LDAP server for this? Thanks, Scott FYI, I also tried setting up an openldap-server with this entry: [root@vm3 ~]# ldapsearch -x -D 'cn=admin,dc=example,dc=test' -w Secret123 -b uid=nonposix,ou=users,dc=example,dc=test # extended LDIF # # LDAPv3 # base <uid=nonposix,ou=users,dc=example,dc=test> with scope subtree # filter: (objectclass=*) # requesting: ALL # # nonposix, users, example.test dn: uid=nonposix,ou=users,dc=example,dc=test displayName: new user uid: nonposix objectClass: person objectClass: top objectClass: inetOrgPerson initials: nu sn: user mail: nonposix givenName: new cn: new user userPassword:: e1NTSEF9OHpPNUFxZFo0ZG1BcDNIcldxLzBWeGU5QVBBdjhtOFM= # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 And I pointed sssd to this: [root@vm2 ~]# cat /etc/sssd/sssd.conf [domain/app1] debug_level = 10 id_provider = ldap ldap_uri = ldap://vm3.example.com ldap_search_base = dc=example,dc=test ldap_user_extra_attrs = mail, firstname:givenname, lastname:sn ldap_user_object_class = person domain_type = application ... This was in addition to the IPA client sssd.conf setup I listed above. I can find it with dbus-send: [root@vm2 ~]# sh -x dbus_search + dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:nonposix array:string:mail method return sender=:1.93 -> dest=:1.97 reply_serial=2 array [ dict entry( string "mail" variant array [ string "nonposix" ] ) ] But, I cannot access it via curl: [root@vm2 ~]# curl -u nonposix:NewPass http://$(hostname)/app1/index.shtml FAIL I believe you should add [pam] pam_app_services = app1 to your sssd.conf to enable PAM for the domain_type = application domain. That was part of it. Turns out I needed to also configure ldap_tls_cacert for the LDAP domain...and fix the name. I think that was most of it. Verified. Version :: sssd-1.15.2-37.el7.x86_64 mod_lookup_identity-1.0.0-1.el7.x86_64 Results :: # Setup: IPA Server, IPA Client and openldap-server on 3 separate hosts # I will attach ldap server setup separately in case anyone wants to see that. # LDAP nonposix user: [root@vm3 ~]# cat nonposix.ldif dn: uid=nonposix,ou=users,dc=example,dc=test displayName: new user uid: nonposix objectClass: person objectClass: top objectClass: inetorgperson initials: nu sn: user mail: nonposix givenName: new cn: new user # IPA Client setup as web server for testing: [root@client ~]# cat /etc/httpd/conf.d/app1.conf LoadModule authnz_pam_module modules/mod_authnz_pam.so LoadModule lookup_identity_module modules/mod_lookup_identity.so <Location /app1> AuthType Basic AuthName "private area" AuthBasicProvider PAM AuthPAMService app1 Require valid-user ErrorDocument 401 'FAIL' LookupUserAttr mail REMOTE_USER_EMAIL " " LookupUserAttr firstname REMOTE_USER_FIRSTNAME LookupUserAttr lastname REMOTE_USER_LASTNAME LookupUserAttr gidNumber REMOTE_USER_GID LookupUserAttr uidNumber REMOTE_USER_UID LookupUserGroups REMOTE_USER_GROUPS ":" LookupUserGroupsIter REMOTE_USER_GROUPS LookupUserGroups REMOTE_USER_GROUPS ":" LookupUserGroupsIter REMOTE_USER_GROUPS </Location> <Directory /var/www/html/app1> Options +Includes AddType text/html .shtml AddOutputFilter INCLUDES .shtml </Directory> [root@client ~]# cat /var/www/html/app1/index.shtml <html> <body> REMOTE_ADDR=<!--#echo var="REMOTE_ADDR"--> REMOTE_PORT=<!--#echo var="REMOTE_PORT"--> REMOTE_USER=<!--#echo var="REMOTE_USER"--> REMOTE_USER_UID=<!--#echo var="REMOTE_USER_UID"--> REMOTE_USER_GID=<!--#echo var="REMOTE_USER_GID"--> REMOTE_USER_FIRSTNAME=<!--#echo var="REMOTE_USER_FIRSTNAME"--> REMOTE_USER_LASTNAME=<!--#echo var="REMOTE_USER_LASTNAME"--> REMOTE_USER_GROUPS=<!--#echo var="REMOTE_USER_GROUPS"--> REMOTE_USER_GROUPS_1=<!--#echo var="REMOTE_USER_GROUPS_1"--> REMOTE_USER_GROUPS_N=<!--#echo var="REMOTE_USER_GROUPS_N"--> <hr> </body> </html> [root@client ~]# cat /etc/pam.d/app1 auth required pam_sss.so account required pam_sss.so [root@client ~]# cat /etc/sssd/sssd.conf [domain/example.test] id_provider = ldap ldap_uri = ldap://vm3.example.com ldap_search_base = dc=example,dc=test ldap_user_extra_attrs = mail, firstname:givenname, lastname:sn ldap_user_object_class = person ldap_tls_cacert = /etc/openldap/certs/exampleldapcert.pem domain_type = application [domain/testrelm.test] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = testrelm.test id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client.testrelm.test chpass_provider = ipa ipa_server = _srv_, master.testrelm.test ldap_tls_cacert = /etc/ipa/ca.crt ldap_user_extra_attrs = mail, firstname:givenname, lastname:sn domain_type = application [sssd] services = nss, sudo, pam, ssh, ifp domains = testrelm.test, example.test [nss] homedir_substring = /home [pam] pam_app_services = app1 [sudo] [autofs] [ssh] [pac] [ifp] allowed_uids = apache, root user_attributes = +mail, +firstname, +lastname, +gidNumber, +uidNumber [secrets] # Search for posix IPA user: [root@client ~]# curl -u bob:Secret123 http://$(hostname)/app1/index.shtml <html> <body> REMOTE_ADDR=192.168.122.152 REMOTE_PORT=45076 REMOTE_USER=bob REMOTE_USER_UID=1607600001 REMOTE_USER_GID=1607600001 REMOTE_USER_FIRSTNAME=bob REMOTE_USER_LASTNAME=belcher REMOTE_USER_GROUPS=ipausers REMOTE_USER_GROUPS_1=ipausers REMOTE_USER_GROUPS_N=1 <hr> </body> </html> # Search for nonposix LDAP user: [root@client ~]# curl -u nonposix:NewPass http://$(hostname)/app1/index.shtml <html> <body> REMOTE_ADDR=192.168.122.152 REMOTE_PORT=45090 REMOTE_USER=nonposix REMOTE_USER_UID=(none) REMOTE_USER_GID=0 REMOTE_USER_FIRSTNAME=new REMOTE_USER_LASTNAME=user REMOTE_USER_GROUPS=(none) REMOTE_USER_GROUPS_1=(none) REMOTE_USER_GROUPS_N=0 <hr> </body> </html> Created attachment 1284152 [details]
ldap server and user setup for verification
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/RHEA-2017:2115 |