Am Wed, Oct 27, 2021 at 07:58:50AM -0000 schrieb Mark Johnson via FreeIPA-users:
I've been struggling with this all day and I'm getting
nowhere. We're wanting to migrate from a 389-DS authenticated network to FreeIPA. We
have a few Linux servers scattered around the world that authenticate against our current
389 directory and we're wanting to do this with minimal changes to these servers. The
thought process is to perform LDAP auth against FreeIPA and filter access permissions by
way of an LDAP access filter based on group membership as we are currently doing with 389,
so we just need to make config changes to sssd to point to the new servers (and install
the required certificate to do so).
FreeIPA servers are already setup and replicating. Set up a couple of test groups and a
handful of test user accounts. I can successfully authenticate these users, but I get a
permission denied seemingly at the access filter stage.
Oct 27 04:15:09 autugd6998 sshd[9984]: pam_sss(sshd:auth): authentication success;
logname= uid=0 euid=0 tty=ssh ruser= rhost=10.66.67.69 user=markj
Oct 27 04:15:09 autugd6998 sshd[9984]: pam_sss(sshd:account): Access denied for user
markj: 6 (Permission denied)
Same result for a console login. To test this, I changed the access_provider to
'permit' and I can successfully log in to the server. So, it's as if I'm
having issues with my access filter, but everything I've tried is giving me the same
result. I've used these same filters in ldapsearch tests and they seem to work fine.
For instance, I've created a group called "serveradmins" and placed a couple
of users in that group. My sssd.conf ldap_access_filter looks like this:
access_provider = ldap
ldap_access_filter =
memberOf=cn=serveradmins,cn=groups,cn=accounts,dc=ipa,dc=domain,dc=com
Hi,
one possible solution might be to do it the FreeIPA way and create and
HBAC rule which allows members of the group to log in with all services.
With this all configuration will be done on the server side and you do
not need additional options in sssd.conf on the client.
If you prefer to use 'access_provider = ldap' you might need some more
LDAP provider specific options. Although the IPA provider is using LDAP
as well the options are not shared here. To figure out waht is missing
it might be most easy to add 'debug_level = 9' in the [domain/...]
section of sssd.conf, restart SSSD, try to login again and the check the
backend logs. The access control part in the log can be found by
searching for 'PAM Account #' there is this string with a number at the
start and the end of the access control validation.
HTH
bye,
Sumit
But that just isn't working. However, if I issue the following, I can see the group
members:
$ ldapsearch -x -W -LLL -H
ldap://ussv4p6004.ipa.domain.com -b
cn=serveradmins,cn=groups,cn=accounts,dc=ipa,dc=domain,dc=com -D
"uid=markj,cn=users,cn=accounts,dc=ipa,dc=domain,dc=com"
Enter LDAP Password:
dn: cn=serveradmins,cn=groups,cn=accounts,dc=ipa,dc=domain,dc=com
member: uid=mark,cn=users,cn=accounts,dc=ipa,dc=domain,dc=com
member: uid=markj,cn=users,cn=accounts,dc=ipa,dc=domain,dc=com
cn: serveradmins
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
ipaUniqueID: 2e489422-36c2-11ec-a8a8-52540031af07
I've tried different groups including the default 'ipausers' group which
everyone is a member of but I'm getting nowhere.
For the record, here's a snippet from the server audit.log when I fail to login. Not
sure if that "PAM:accounting grantors=?" bit where the USER_ACCT fails is
indicative of the problem or not but if so, I'm not sure what that means and how to
resolve it. However, the same server works on the old 389 directory using LDAP auth -
just have no idea what I'm missing.
type=USER_AUTH msg=audit(1635321247.300:1039): pid=10122 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey
acct="markj" exe="/usr/sbin/sshd" hostname=? addr=10.66.67.69
terminal=ssh res=failed'
type=USER_AUTH msg=audit(1635321252.664:1040): pid=10122 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication
grantors=pam_succeed_if,pam_succeed_if,pam_sss acct="markj"
exe="/usr/sbin/sshd" hostname=10.66.67.69 addr=10.66.67.69 terminal=ssh
res=success'
type=USER_ACCT msg=audit(1635321252.855:1041): pid=10122 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:accounting
grantors=? acct="markj" exe="/usr/sbin/sshd" hostname=10.66.67.69
addr=10.66.67.69 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1635321252.856:1042): pid=10122 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=password
acct="markj" exe="/usr/sbin/sshd" hostname=? addr=10.66.67.69
terminal=ssh res=failed'
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure