SSSD / sssd

Clone

#3765 SSSD does not support login as a Kerberos alias to IPA user
Closed: wontfix 4 years ago by pbrezina. Opened 5 years ago by abbra.

Closed: wontfix
Reopen Issue

FreeIPA supports adding Kerberos aliases to user objects. It allows one to kinit as an alias and get back a TGT for the original primary Kerberos principal.

However, SSSD does not recognize the alias during authentication which makes it not possible to use aliases for both POSIX and application specific domains.

# ipa user-add mbar
First name: M
Last name: Bar
-----------------
Added user "mbar"
-----------------
  User login: mbar
  First name: M
  Last name: Bar
  Full name: M Bar
  Display name: M Bar
  Initials: MB
  Home directory: /home/mbar
  GECOS: M Bar
  Login shell: /bin/sh
  Principal name: mbar@XS.IPA.COOL
  Principal alias: mbar@XS.IPA.COOL
  Email address: mbar@xs.ipa.cool
  UID: 1536000097
  GID: 1536000097
  Password: False
  Member of groups: ipausers
  Kerberos keys available: False

# ipa user-add-principal mbar fbar
--------------------------------
Added new aliases to user "mbar"
--------------------------------
  User login: mbar
  Principal alias: mbar@XS.IPA.COOL, fbar@XS.IPA.COOL

Such user entry will have following attributes:

# ipa user-show mbar --all --raw
  dn: uid=mbar,cn=users,cn=accounts,dc=xs,dc=ipa,dc=cool
  uid: mbar
  givenname: M
  sn: Bar
  cn: M Bar
  initials: MB
  homedirectory: /home/mbar
  gecos: M Bar
  loginshell: /bin/sh
  krbcanonicalname: mbar@XS.IPA.COOL
  krbprincipalname: mbar@XS.IPA.COOL
  krbprincipalname: fbar@XS.IPA.COOL
  mail: mbar@xs.ipa.cool
  uidnumber: 1536000097
  gidnumber: 1536000097
  nsaccountlock: FALSE
  has_password: TRUE
  has_keytab: TRUE
  displayName: M Bar
  ipaNTSecurityIdentifier: S-1-5-21-570121326-3336757064-1157332047-1097
  ipaUniqueID: 86f707d6-76c0-11e8-99bc-001a4a62eb77
  krbExtraData: AAK3Bi5bYWRtaW4vYWRtaW5AWFMuSVBBLkNPT0wA
  krbLastPwdChange: 20180623083711Z
  krbLastSuccessfulAuth: 20180623083833Z
  krbLoginFailedCount: 0
  krbPasswordExpiration: 20180921083711Z
  krbTicketFlags: 128
  memberof: cn=ipausers,cn=groups,cn=accounts,dc=xs,dc=ipa,dc=cool
  mepManagedEntry: cn=mbar,cn=groups,cn=accounts,dc=xs,dc=ipa,dc=cool
  objectClass: top
  objectClass: person
  objectClass: organizationalperson
  objectClass: inetorgperson
  objectClass: inetuser
  objectClass: posixaccount
  objectClass: krbprincipalaux
  objectClass: krbticketpolicyaux
  objectClass: ipaobject
  objectClass: ipasshuser
  objectClass: ipaSshGroupOfPubKeys
  objectClass: mepOriginEntry
  objectClass: ipantuserattrs

An attempt to login as fbar leads to this:

(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][name=fbar@xs.ipa.cool]
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [dp_attach_req] (0x0400): DP Request [Account #202]: New request. Flags [0x0001].
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [dp_attach_req] (0x0400): Number of active DP request: 1
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sss_domain_get_state] (0x1000): Domain xs.ipa.cool is Active
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sss_domain_get_state] (0x1000): Domain xs.ipa.cool is Active
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [cn=accounts,dc=xs,dc=ipa,dc=cool]
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_print_server] (0x2000): Searching a.b.c.d:389
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=fbar)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=xs,dc=ipa,dc=cool].
......
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_op_destructor] (0x2000): Operation 55 finished
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results.
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_search_user_process] (0x2000): Retrieved total 0 users
....
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_id_op_done] (0x4000): releasing operation connection
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [dp_req_done] (0x0400): DP Request [Account #202]: Request handler finished [0]: Success
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [_dp_req_recv] (0x0400): DP Request [Account #202]: Receiving request data.
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [dp_req_reply_list_success] (0x0400): DP Request [Account #202]: Finished. Success.
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [dp_req_reply_std] (0x1000): DP Request [Account #202]: Returning [Success]: 0,0,Success
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:1::xs.ipa.cool:name=fbar@xs.ipa.cool] from reply table
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [dp_req_destructor] (0x0400): DP Request [Account #202]: Request removed.
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [dp_req_destructor] (0x0400): Number of active DP request: 0
(Sat Jun 23 10:38:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_process_result] (0x2000): Trace: sh[0x564ad409cef0], connected[1], ops[(nil)], ldap[0x564ad402eb80]

We can discuss whether it is useful to map the alias on POSIX level but at least for authentication purposes in application domains I think it should be very useful operation.

Note that this is primarily affecting password-based login, of course. One use case we've seen at freenode's #kerberos IRC channel is a use of FreeIPA and PAM to authenticate users inside MySQL.

There is a limitation inside MySQL code that user names must be less than 16 characters long and a user tried to overcome it by adding a Kerberos principal alias. Both pam_krb5 and SSSD fail working with aliases in such case. pam_krb5 produces unparsable principals when canonicalize = true is set in pam_krb5 configuration and SSSD does not recognize the alias at all.

pam_krb5 bug: https://pagure.io/pam_krb5/issue/2

Currently Kerberos aliases are only supported as principals. I would expect that if you try to login as fbar@XS.IPA.COOL authentication would succeed.

I'm a bit reluctant here to allow the plain name component of a Kerberos alias as a short user name because in theory there are two different name spaces with individual uniqueness requirements. IPA tries it's best to make sure that those name spaces are treated as one but I'm afraid that there will be more request in this direction, e.g. using the name component of AD's userPrincipalName attribute for a similar purpose.

I understand the IPA basically treats Kerberos aliases as name aliases, but wouldn't it be more straight forward to have a separate attribute with the short name aliases as well? It would be a bit redundant but on the other hand might help to make tie easier to offer this feature via the compat tree as well.

For application domains having a principal support would be enough -- this would allow the MySQL PAM use case which prompted this issue. Can we enable that?

Having a separate attribute for short name aliases is something that I didn't look into. It would make life on the server side harder as maintaining coherence across multiple attributes is complex. uid attribute already allows for multiple values in LDAP schema and we utilize it in the compat tree for AD users but to date we haven't made an attempt to do so for the primary IPA tree. IPA framework forces a single value for uid so it is surely not prepared for seeing multivalued uid.

Using a Kerberos alias principal as login name is enabled by default and should be transparent to the domain type. Do you see issues with a specific configuration?

Yes, I do. See the original bug report -- as authentication name is derived from the local username by sshd, it falls short at the point when local username (alias) is not found, thus not even going to authentication.

What version of SSSD are you using? It works fine for me on RHEL-7.5

[root@ipaserver75 ~]# ssh -l abc123@RHEL75.DEVEL localhost
Password: 
Last login: Mon Jun 25 13:01:43 2018 from localhost
Could not chdir to home directory /home/aliastest: No such file or directory
-sh-4.2$ id
uid=1999600010(aliastest) gid=1999600010(aliastest) Gruppen=1999600010(aliastest) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-sh-4.2$ ipa user-show aliastest | grep -i princ
ipa: ERROR: Could not create log_dir u'/home/aliastest/.ipa/log'
ipa: WARNING: Failed to write schema: [Errno 13] Keine Berechtigung: '/home/aliastest'
ipa: WARNING: Failed to write server info: [Errno 13] Keine Berechtigung: '/home/aliastest'
  Principal-Name: aliastest@RHEL75.DEVEL
  Principal alias: aliastest@RHEL75.DEVEL, abc123@RHEL75.DEVEL, admin\@other.realm@RHEL75.DEVEL
-sh-4.2$

Please note you really have to specify the full Kerberos alias as login name.

I did a setup with an application domain and a separate PAM service, using alias doesn't work there either.

# cat /etc/sssd/conf.d/sssd.conf 
[application/sss_test]
inherit_from = domain/xs.ipa.cool
domain_type=application

[pam]
pam_app_services = sss_test

# ln -s /etc/pam.d/system-auth /etc/pam.d/sss_test
# python3
Python 3.6.5 (default, Mar 29 2018, 18:20:46) 
[GCC 8.0.1 20180317 (Red Hat 8.0.1-0.19)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pam
>>> p = pam.pam()
>>> p.authenticate('fbar', 'Test1234', service='sss_test')
False
>>> p.authenticate('fbar@xs.ipa.cool', 'Test1234', service='sss_test')
False
>>> 
>>> p.authenticate('fbar@XS.IPA.COOL', 'Test1234', service='sss_test')
False

Looking at the SSSD logs, I can see this:

(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][name=fbar@XS.IPA.COOL]
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [dp_attach_req] (0x0400): DP Request [Account #5]: New request. Flags [0x0001].
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [dp_attach_req] (0x0400): Number of active DP request: 1
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sss_domain_get_state] (0x1000): Domain xs.ipa.cool is Active
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sss_domain_get_state] (0x1000): Domain xs.ipa.cool is Active
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [cn=accounts,dc=xs,dc=ipa,dc=cool]
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_print_server] (0x2000): Searching a.b.c.d:389
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(|(krbPrincipalName=fbar@XS.IPA.COOL)(mail=fbar@XS.IPA.COOL)(krbPrincipalName=fbar\\@XS.IPA.COOL@XS.IPA.COOL))(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][cn=accounts,dc=xs,dc=ipa,dc=cool].
....
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_parse_entry] (0x1000): OriginalDN: [uid=mbar,cn=users,cn=accounts,dc=xs,dc=ipa,dc=cool].
...
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_search_user_process] (0x0400): Search for users, returned 1 results.
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_search_user_process] (0x2000): Retrieved total 1 users
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [ldb] (0x4000): start ldb transaction (nesting: 0)
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_save_user] (0x0400): Save user
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sss_domain_get_state] (0x1000): Domain xs.ipa.cool is Active
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_get_primary_name] (0x0400): Processing object mbar
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_save_user] (0x0400): Processing user mbar@xs.ipa.cool
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_save_user] (0x2000): Adding originalDN [uid=mbar,cn=users,cn=accounts,dc=xs,dc=ipa,dc=cool] to attributes of [mbar@xs.ipa.cool].
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [mbar@xs.ipa.cool].
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20180623083833Z] to attributes of [mbar@xs.ipa.cool].
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_save_user] (0x0400): Adding user principal [mbar@XS.IPA.COOL] to attributes of [mbar@xs.ipa.cool].
(Mon Jun 25 12:54:38 2018) [sssd[be[xs.ipa.cool]]] [sdap_save_user] (0x0400): Adding user principal [fbar@XS.IPA.COOL] to attributes of [mbar@xs.ipa.cool].

Finally, from pam backend perspective, this looks like the following:

(Mon Jun 25 13:06:08 2018) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'fbar@XS.IPA.COOL' matched expression for domain 'xs.ipa.cool', user is fbar
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): domain: xs.ipa.cool
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): user: fbar
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): service: sss_test
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): tty: not set
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 15805
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_print_data] (0x0100): logon name: fbar@XS.IPA.COOL
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [pam_initgr_check_timeout] (0x4000): User [fbar@XS.IPA.COOL] not found in PAM cache.
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_set_plugin] (0x2000): CR #1: Setting "Initgroups by name" plugin
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_send] (0x0400): CR #1: New request 'Initgroups by name'
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_process_input] (0x0400): CR #1: Parsing input name [fbar@XS.IPA.COOL]
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [sss_domain_get_state] (0x1000): Domain implicit_files is Active
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [sss_domain_get_state] (0x1000): Domain xs.ipa.cool is Active
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'fbar@XS.IPA.COOL' matched expression for domain 'xs.ipa.cool', user is fbar
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_set_name] (0x0400): CR #1: Setting name [fbar]
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_select_domains] (0x0400): CR #1: Performing a single domain search
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [sss_domain_get_state] (0x1000): Domain implicit_files is Active
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [sss_domain_get_state] (0x1000): Domain xs.ipa.cool is Active
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_search_domains] (0x0400): CR #1: Search will bypass the cache and check the data provider
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_validate_domain_type] (0x2000): Request type Application-only for domain xs.ipa.cool type POSIX is not valid
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_validate_domain_type] (0x2000): Request type Application-only for domain ad.ipa.cool type POSIX is not valid
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_global_ncache_add] (0x2000): CR #1: This request type does not support global negative cache
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_set_plugin] (0x2000): CR #1: Setting "Initgroups by UPN" plugin
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_set_name] (0x0400): CR #1: Setting name [fbar@XS.IPA.COOL]
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_assume_upn] (0x0400): CR #1: Assuming UPN [fbar@XS.IPA.COOL]
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_select_domains] (0x0400): CR #1: Performing a multi-domain search
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_search_domains] (0x0400): CR #1: Search will bypass the cache and check the data provider
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_validate_domain_type] (0x2000): Request type Application-only for domain implicit_files type POSIX is not valid
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_validate_domain_type] (0x2000): Request type Application-only for domain xs.ipa.cool type POSIX is not valid
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_validate_domain_type] (0x2000): Request type Application-only for domain ad.ipa.cool type POSIX is not valid
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_global_ncache_add] (0x2000): CR #1: This request type does not support global negative cache
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [cache_req_process_result] (0x0400): CR #1: Finished: Not found
(Mon Jun 25 13:06:08 2018) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x5566cbcfccd0

Could you please help me define the application domain properly so that it would be matched?

This is Fedora 28:

# rpm -q sssd
sssd-1.16.2-1.fc28.x86_64

What is missing I guess is 'sss_test' in the domains list in /etc/sssd/sssd.conf. We are working on allowing domain enablement in the [application/...] sections as well (https://pagure.io/SSSD/sssd/issue/3735) but so far it is as said in the sssd.conf man page

Please note that the application domain must still be explicitly enabled in the “domains” parameter so that the lookup order between the application domain and its POSIX sibling domain is set correctly.

Nevertheless even if you add this I would expect that it will not work as expected (at least it didn't do so in my testing) because as sssd.conf says as well:

NOTE: The application domains are currently well tested with “id_provider=ldap” only.

What worked for me is a LDAP configuration for the application domain like:

[application/sssd_test]
#inherit_from = rhel75.devel
id_provider = ldap
ldap_uri = ldap://ipaserver75.rhel75.devel
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/f25.fed.devel@RHEL75.DEVEL
ldap_search_base = cn=accounts,dc=rhel75,dc=devel
krb5_realm = RHEL75.DEVEL
krb5_server = ipaserver75.rhel75.devel
domain_type=application

So there are a few things to fix to make application domains work with the IPA provider, so we can keep the ticket open.

Nevertheless I'm wondering, since application domains where created to make user and groups without POSIX attributes available to applications and by default those objects in IPA have POSIX attributes, why an application domain is needed for the MySQL use case, since the same names are available with the plain IPA domain as well?

I obtained those logs above with sss_test domain being in the list of enabled domains.

The configuration with id_provider = ldap does not work. When I issue PAM authenticate request as fbar@XS.IPA.COOL, the sss_test domain gets a request as mbar@sss_test and that fails:

(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [dp_pam_handler] (0x0100): Got request with the following data
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): domain: xs.ipa.cool
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): user: mbar@sss_test
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): service: sss_test
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): tty: 
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): ruser: 
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): rhost: 
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): authtok type: 1
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): newauthtok type: 0
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): priv: 1
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): cli_pid: 13900
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [pam_print_data] (0x0100): logon name: not set
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [dp_attach_req] (0x0400): DP Request [PAM Authenticate #7]: New request. Flags [0000].
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [dp_attach_req] (0x0400): Number of active DP request: 1
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [sss_domain_get_state] (0x1000): Domain sss_test is Active
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [dp_req_new] (0x0020): Unknown domain: xs.ipa.cool
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [_dp_req_recv] (0x0400): DP Request [PAM Authenticate #7]: Receiving request data.
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [dp_req_destructor] (0x0400): DP Request [PAM Authenticate #7]: Request removed.
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [dp_req_destructor] (0x0400): Number of active DP request: 0
(Tue Jun 26 13:12:06 2018) [sssd[be[sss_test]]] [dp_req_reply_gen_error] (0x0020): DP Request [PAM Authenticate #7]: Finished. Error [1432158244]: Domain not found

Nevertheless I'm wondering, since application domains where created to make user and groups
without POSIX attributes available to applications and by default those objects in IPA have POSIX
attributes, why an application domain is needed for the MySQL use case, since the same names
are available with the plain IPA domain as well?

Because, as I said before, you cannot 'id' the alias, so use of pam_sss inside MySQL PAM stack would not work at all -- SSSD will attempt to find POSIX user with the alias as a name and will fail, aborting the authentication flow.
Edited 5 years ago by abbra

Did you try to use 'sss_test' as first entry in the domains list?

Yes, putting it the first works. Thanks.

So, to wrap up:

  • use application domain with id_provider = ldap and setting it up similar to id_provider = ipa defaults (for both LDAP and Kerberos)
  • define this application domain in the domains = ... before the actual IPA domain in [sssd]
  • allow the PAM service that will be querying the application domain in pam_app_services option in [pam]

.. makes Kerberos principal aliases usable in PAM application.

Could you just please remove the @DOMAIN from the string when trying to search the id provider when ldap_user_name = krbPrincipalName ?

Because when it does the ldap search for my user name when ldap_user_name = krbPrincipalName it's getting back ballison@CORP.MYCOMPANY.COM. But the username it's being passed is just "ballison" so those two are never going to match.

$ ldapsearch -N -Y GSSAPI -h freeipa.corp.mycompany.com -b "cn=users,cn=accounts,dc=corp,dc=mycompany,dc=com" uid=brad.allison krbprincipalname 2>&1| egrep "dn:|^krbprincipalname"
dn: uid=brad.allison,cn=users,cn=accounts,dc=corp,dc=mycompany,dc=com
krbprincipalname: brad.allison@CORP.MYCOMPANY.COM
krbprincipalname: ballison@CORP.MYCOMPANY.COM

So I have mysqld set up to use the "auth_pam" module which reads /etc/pam.d/mysqld which in turn called the pam_sss.so module which would interact with sssd.

$ cat /etc/pam.d/mysqld
auth sufficient pam_sss.so forward_pass
account [default=bad success=ok user_unknown=ignore] pam_sss.so
password sufficient pam_sss.so use_authtok
session optional pam_sss.so

Given that.. I'm not sure I understand why I would have a [pam] in the sssd.conf telling it to call itself? Seems like recursive logic. I'm not following this.

I have all this working for full usernames in ipa/kerberos

But when I try the short alias names it's failing to ever get past the id_provider list because it's not matching the alias names.
Edited 5 years ago by jackal242

Don't use ldap_user_name = krbPrincipalName in the application domain definition. It is wrong and is not needed.

Given that.. I'm not sure I understand why I would have a [pam] in the sssd.conf telling it to call itself? Seems like recursive logic. I'm not following this.

[pam] section settings define which PAM apps (pam service names) are allowed to use application domains in SSSD. These are security constraints, we don't want all PAM services to perform these operations, only selected ones. By default none of them are allowed.

You also need to allow a specific UID which is used by mysqld to access SSSD for these operations.

1- I have this working for mysqld-> pam_auth -> /etc/pam.d/mysql -> pam_sss.so -> /etc/sssd/sssd.conf and I have all that working for logging into mysql using a full kerberos principal. So I'm not sure what, "You also need to allow a specific UID which is used by mysqld to access SSSD for these operations." means.

2- In my sssd.conf I have it set up
id_provider = ipa
auth_provider = krb5

Which I switch that to id_provider = ldap everything fails because it never finds the user name in the ldap list of employees.

3- I'm trying to get this to work with kerberos aliases... and where it seems to fail is looking up the user in ldap. Because it's looking for the username passed by mysql -uUSERNAME and which never matches anything in the ldap response because nothing in ldap is called by the alias name. that name is only present in the krbPrincipalName field. And that doesn't work either because USERNAME does not match USERNAME@DOMAIN.

Metadata Update from @pbrezina:
- Issue tagged with: Canditate to close
4 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)
4 years ago

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/4771

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.

Login to comment on this ticket.

Metadata
None

Candidate to close

None
None
minor
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.