(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