Re: [Freeipa-users] Password-based authentication with AD users does not work
On Mon, Apr 10, 2017 at 11:49:05AM +0200, Ronald Wimmer wrote: > On 2017-04-07 10:28, Sumit Bose wrote: > > [...] > > I'm not aware of any limitation here. Have you tried to run 'ipa > > trust-fetch-domains ad.forest.root' to update the list? > > > > If this does not help please add 'log level = 100' to > > /usr/share/ipa/smb.conf.empty so that it looks like: > > > > [global] > > log level = 100 > > > > and run trust-fetch-domains again. The debug output can then be found > > in /var/log/httpd/error_log. [...] > > Not one error in the error_log - absolutely nothing. Our AD guys confirmed > that there are many more UPN suffixes than the five I can see when I run ipa > trust-find. > > Can somebody confirm that this UPN suffix mismatch is exactly the problem > preventing password-based login in my case? To close the thread, it turned out that the original issue with authenticating with enterprise principals is a bug which is now tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1441077. bye, Sumit > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On 2017-04-07 10:28, Sumit Bose wrote: [...] I'm not aware of any limitation here. Have you tried to run 'ipa trust-fetch-domains ad.forest.root' to update the list? If this does not help please add 'log level = 100' to /usr/share/ipa/smb.conf.empty so that it looks like: [global] log level = 100 and run trust-fetch-domains again. The debug output can then be found in /var/log/httpd/error_log. [...] Not one error in the error_log - absolutely nothing. Our AD guys confirmed that there are many more UPN suffixes than the five I can see when I run ipa trust-find. Can somebody confirm that this UPN suffix mismatch is exactly the problem preventing password-based login in my case? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On Fri, Apr 07, 2017 at 09:46:45AM +0200, Ronald Wimmer wrote: > On 2017-04-06 20:50, Sumit Bose wrote: > > On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote: > > > On 2017-04-06 12:16, Sumit Bose wrote: > > > > On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: > > > > [...] > > > > > AD trust: > > > > > mydomain.at (forest root) > > > > > xyz (subdomain -> where myuser resides) > > > > > > > > > > BCC (appearing in krb5_child.log) is not a domain here. It is my > > > > > company's > > > > > name and might derive from some information in the AD. > > > > Yes, it is about the userPrincipalName attribute read from AD. Which IPA > > > > server version do you use? Since RHEL-7.3 IPA supports those principals > > > > coming from AD. For older versions you should add a workaround which is > > > > e.g. described at the end of > > > > https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html > > > > > > > > HTH > > > > > > > > bye, > > > > Sumit > > > > > > I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to > > > override it? > > > > Please check on the server with > > > > ipa trust-find > > > > if the BCC domain is listed as 'UPN suffixes:'. If not please try > > > > ipa trust-fetch-domains > > > > and check again. If the domain is listed then a 7.3 IPA client should be > > able to detect it automatically on older clients you should set > > 'krb5_use_enterprise_principal = True' manually in sssd.conf. > > I just checked with our AD guys. ipa trust-find only shows five UPN > suffixes. There are many more which are not shown inlcuding bcc.mydomain.at > > Any idea why only a subset is shown? I'm not aware of any limitation here. Have you tried to run 'ipa trust-fetch-domains ad.forest.root' to update the list? If this does not help please add 'log level = 100' to /usr/share/ipa/smb.conf.empty so that it looks like: [global] log level = 100 and run trust-fetch-domains again. The debug output can then be found in /var/log/httpd/error_log. The logs might contain data which should not be shared publicly, so feel free to send them to me directly. bye, Sumit > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On 2017-04-06 20:50, Sumit Bose wrote: On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote: On 2017-04-06 12:16, Sumit Bose wrote: On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: [...] AD trust: mydomain.at (forest root) xyz (subdomain -> where myuser resides) BCC (appearing in krb5_child.log) is not a domain here. It is my company's name and might derive from some information in the AD. Yes, it is about the userPrincipalName attribute read from AD. Which IPA server version do you use? Since RHEL-7.3 IPA supports those principals coming from AD. For older versions you should add a workaround which is e.g. described at the end of https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html HTH bye, Sumit I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to override it? Please check on the server with ipa trust-find if the BCC domain is listed as 'UPN suffixes:'. If not please try ipa trust-fetch-domains and check again. If the domain is listed then a 7.3 IPA client should be able to detect it automatically on older clients you should set 'krb5_use_enterprise_principal = True' manually in sssd.conf. I just checked with our AD guys. ipa trust-find only shows five UPN suffixes. There are many more which are not shown inlcuding bcc.mydomain.at Any idea why only a subset is shown? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
Zitat von Sumit Bose : On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote: On 2017-04-06 12:16, Sumit Bose wrote: > On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: > [...] > > AD trust: > > mydomain.at (forest root) > > xyz (subdomain -> where myuser resides) > > > > BCC (appearing in krb5_child.log) is not a domain here. It is my company's > > name and might derive from some information in the AD. > Yes, it is about the userPrincipalName attribute read from AD. Which IPA > server version do you use? Since RHEL-7.3 IPA supports those principals > coming from AD. For older versions you should add a workaround which is > e.g. described at the end of > https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html > > HTH > > bye, > Sumit I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to override it? Please check on the server with ipa trust-find if the BCC domain is listed as 'UPN suffixes:'. If not please try ipa trust-fetch-domains and check again. If the domain is listed then a 7.3 IPA client should be able to detect it automatically on older clients you should set 'krb5_use_enterprise_principal = True' manually in sssd.conf. Unfortunately, ipa trust-find shows some UPN suffixes but BCC is not in the list. Any other options left? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote: > On 2017-04-06 12:16, Sumit Bose wrote: > > On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: > > [...] > > > AD trust: > > > mydomain.at (forest root) > > > xyz (subdomain -> where myuser resides) > > > > > > BCC (appearing in krb5_child.log) is not a domain here. It is my company's > > > name and might derive from some information in the AD. > > Yes, it is about the userPrincipalName attribute read from AD. Which IPA > > server version do you use? Since RHEL-7.3 IPA supports those principals > > coming from AD. For older versions you should add a workaround which is > > e.g. described at the end of > > https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html > > > > HTH > > > > bye, > > Sumit > > I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to > override it? Please check on the server with ipa trust-find if the BCC domain is listed as 'UPN suffixes:'. If not please try ipa trust-fetch-domains and check again. If the domain is listed then a 7.3 IPA client should be able to detect it automatically on older clients you should set 'krb5_use_enterprise_principal = True' manually in sssd.conf. HTH bye, Sumit > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On 2017-04-06 12:16, Sumit Bose wrote: On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: [...] AD trust: mydomain.at (forest root) xyz (subdomain -> where myuser resides) BCC (appearing in krb5_child.log) is not a domain here. It is my company's name and might derive from some information in the AD. Yes, it is about the userPrincipalName attribute read from AD. Which IPA server version do you use? Since RHEL-7.3 IPA supports those principals coming from AD. For older versions you should add a workaround which is e.g. described at the end of https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html HTH bye, Sumit I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to override it? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote: > On 2017-04-06 11:21, Sumit Bose wrote: > > On Thu, Apr 06, 2017 at 12:10:29PM +0200, Ronald Wimmer wrote: > > > Hi, > > > > > > when I try to login to an IPA client with my AD user it works perfectly > > > when > > > I already have a kerberos ticket for my user. When I do not and I try a > > > password-based login it fails: > > Please send the sssd_domain.log and krb5_child.log form the same time as > > well. > > > > AD trust: > mydomain.at (forest root) > xyz (subdomain -> where myuser resides) > > BCC (appearing in krb5_child.log) is not a domain here. It is my company's > name and might derive from some information in the AD. Yes, it is about the userPrincipalName attribute read from AD. Which IPA server version do you use? Since RHEL-7.3 IPA supports those principals coming from AD. For older versions you should add a workaround which is e.g. described at the end of https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html HTH bye, Sumit -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On 2017-04-06 12:58, Ronald Wimmer wrote: [...] BCC (appearing in krb5_child.log) is not a domain here. It is my company's name and might derive from some information in the AD. After doing an LDAP search on the domain controller of my AD domain (xyz.mydomain.at) I found out that my userPrincipalName is myu...@bcc.mydomain.at - this can definitely not be changed! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password-based authentication with AD users does not work
On 2017-04-06 11:21, Sumit Bose wrote: On Thu, Apr 06, 2017 at 12:10:29PM +0200, Ronald Wimmer wrote: Hi, when I try to login to an IPA client with my AD user it works perfectly when I already have a kerberos ticket for my user. When I do not and I try a password-based login it fails: Please send the sssd_domain.log and krb5_child.log form the same time as well. AD trust: mydomain.at (forest root) xyz (subdomain -> where myuser resides) BCC (appearing in krb5_child.log) is not a domain here. It is my company's name and might derive from some information in the AD. sssd_domain.log snippet: [] (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f14f467feb0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.pamHandler on path /org/freedesktop/sssd/dataprovider (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [dp_pam_handler] (0x0100): Got request with the following data (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): domain: XYZ (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): user: myu...@xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): service: sshd (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): tty: ssh (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): ruser: (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): rhost: chupacabra.ipa.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): authtok type: 1 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): priv: 1 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): cli_pid: 31812 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [pam_print_data] (0x0100): logon name: not set (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [dp_attach_req] (0x0400): DP Request [PAM Authenticate #15]: New request. Flags []. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [dp_attach_req] (0x0400): Number of active DP request: 1 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [krb5_auth_queue_send] (0x1000): Wait queue of user [myu...@xyz.mydomain.at] is empty, running request [0x7f14f4670f70] immediately. (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [krb5_setup] (0x4000): No mapping for: myu...@xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f14f468c030 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f14f468c0f0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Running timer event 0x7f14f468c030 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Destroying timer event 0x7f14f468c0f0 "ltdb_timeout" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Ending timer event 0x7f14f468c030 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f14f46aad10 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f14f468c4a0 (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Running timer event 0x7f14f46aad10 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Destroying timer event 0x7f14f468c4a0 "ltdb_timeout" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [ldb] (0x4000): Ending timer event 0x7f14f46aad10 "ltdb_callback" (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_server_status] (0x1000): Status of server 'ipa1.ipa.mydomain.at' is 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_port_status] (0x1000): Port status of port 0 for server 'ipa1.ipa.mydomain.at' is 'working' (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Thu Apr 6 10:39:12 2017) [sssd[be[ipa.mydomain.at]]] [get_server_status] (0x1000): Status of server 'ipa1.ipa.mydomain.at' is 'working' (Thu Apr 6 10:39:12 2017)
Re: [Freeipa-users] Password-based authentication with AD users does not work
On Thu, Apr 06, 2017 at 12:10:29PM +0200, Ronald Wimmer wrote: > Hi, > > when I try to login to an IPA client with my AD user it works perfectly when > I already have a kerberos ticket for my user. When I do not and I try a > password-based login it fails: Please send the sssd_domain.log and krb5_child.log form the same time as well. bye, Sumit > > Password-based: > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_check_user_search] (0x0400): > Returning info for user [myu...@xyz.mydomain.at@xyz.mydomain.at] > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): > User's primary name is myu...@xyz.mydomain.at > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): command: > SSS_PAM_PREAUTH > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: > XYZ > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): user: > myu...@xyz.mydomain.at > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not > set > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: > chupacabra.ipa.mydomain.at > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok > type: 0 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 31816 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): logon > name: myuser > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): > 0x7f4c122ed450 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): > 0x7f4c122ed450 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: > 0x7f4c122e59c0 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): > Dispatching. > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): > received: [4 (System error)][XYZ] > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply > called with result [4]: System error. > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20 > (Thu Apr 6 10:39:12 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x7f4c122f4640][21] > > When I have a Kerberos ticket: > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_check_user_search] (0x0400): > Returning info for user [myu...@xyz.mydomain.at@xyz.mydomain.at] > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): > User's primary name is myu...@xyz.mydomain.at > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): command: > SSS_PAM_OPEN_SESSION > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: > XYZ > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): user: > myu...@xyz.mydomain.at > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not > set > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: > chupacabra.ipa.mydomain.at > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok > type: 0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 31841 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): logon > name: myuser > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): > 0x7f4c122ec4a0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): > 0x7f4c122ec4a0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: > 0x7f4c122e59c0 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): > Dispatching. > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): > received: [0 (Success)][XYZ] > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply > called with result [0]: Success. > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20 > (Thu Apr 6 10:41:00 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x7f4c122f4640][21] >
[Freeipa-users] Password-based authentication with AD users does not work
Hi, when I try to login to an IPA client with my AD user it works perfectly when I already have a kerberos ticket for my user. When I do not and I try a password-based login it fails: Password-based: (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [myu...@xyz.mydomain.at@xyz.mydomain.at] (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is myu...@xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_PREAUTH (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: XYZ (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): user: myu...@xyz.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: chupacabra.ipa.mydomain.at (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 31816 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: myuser (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f4c122ed450 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f4c122ed450 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f4c122e59c0 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][XYZ] (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. (Thu Apr 6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20 (Thu Apr 6 10:39:12 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f4c122f4640][21] When I have a Kerberos ticket: (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [myu...@xyz.mydomain.at@xyz.mydomain.at] (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is myu...@xyz.mydomain.at (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_OPEN_SESSION (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: XYZ (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): user: myu...@xyz.mydomain.at (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: chupacabra.ipa.mydomain.at (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 31841 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: myuser (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f4c122ec4a0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f4c122ec4a0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f4c122e59c0 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][XYZ] (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Thu Apr 6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20 (Thu Apr 6 10:41:00 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f4c122f4640][21] My question is why? Regards, Ronald -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
