On Wed, Feb 15, 2017 at 08:33:39AM -0500, Abhijit Tikekar wrote: > Hi Jakub, > > First I tried ldapsearch without kinit and got the following as expected: > > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: > Unspecified GSS failure. Minor code may provide more information (Ticket > expired) > > > > Ran a kinit with host principal: > > * kinit -k -t /etc/krb5.keytab host/hostname.x.y.local* > > After this, now ldapsearch works fine. Got the results back for the > specified user.
I am suprised that this works, I would expect only the netbios$@realm principal to work, but I guess in your environment host/fqdn@realm is also a computer account.. > > > > > > *# ldapsearch -H ldap://RODChostname.x.ylocal/ -Y GSSAPI -N -b > "dc=x,dc=y,dc=local" > "(&(objectClass=user)(sAMAccountName=first.last))"SASL/GSSAPI > authentication startedSASL username: host/hostname.x.y.local@X.Y.LOCALSASL > SSF: 56SASL data security layer installed.* Are you sure you are using the same LDAP URI, the same base and the same Kerberos principal as SSSD uses? Because down below, SSSD does an alternative of this call, just calling into openldap-libs calls directly. > ... > ... > ... > ... > > But still, the exact same user authentication doesn't work when tried using > SSSD. I would focus on user resolution (so, id $username) before trying out authentication. > > Here is sssd.conf file. > > [sssd] > domains = X.Y.LOCAL > services = nss, pam, sudo > config_file_version = 2 > [nss] > [pam] > [sudo] > [domain/x.y.local] > ad_domain = X.Y.LOCAL > ad_server = hostname.x.y.local > id_provider = ad > auth_provider = ad > access_provider = ad > sudo_provider = ad > ldap_use_tokengroups = False > ldap_sasl_mech = GSSAPI > krb5_realm = X.Y.LOCAL > krb5_store_password_if_offline = True > use_fully_qualified_names = false > dyndns_update = False > ldap_schema = ad > ldap_id_mapping = False > cache_credentials = false > timeout = 1800 > enumerate = True And to make logs cleaner and easier to read, I would suggest to not use enumeration (not mentioning the performance impact enumeration has..) > enum_cache_timeout = 1800 > ldap_use_tokengroups = True Hmm, you first define tokengroups to false, then to true. I think the second setting wins here, but the config is a bit inconsistent then. > > > ldap_uri = ldap://hostname.x.y.local > ldap_sudo_search_base = ... > ldap_user_search_base = ... > ldap_user_object_class = user > ldap_group_search_base = ... > ldap_group_object_class = group > ldap_user_home_directory = unixHomeDirectory > ldap_user_principal = userPrincipalName > ldap_access_order = filter, expire > ldap_account_expire_policy = ad > ldap_access_filter = ... > ldap_access_filter = ... Unless you use any of the providers set to 'ldap', I would recommend against setting the low-level options directly. > override_homedir = /home/%d/%u > default_shell = /bin/bash > > > Many Thanks, > > ~ Abhi > > > > On Wed, Feb 15, 2017 at 4:46 AM, Jakub Hrozek <jhro...@redhat.com> wrote: > > > On Tue, Feb 14, 2017 at 04:32:44PM -0500, Abhijit Tikekar wrote: > > > We created the keytab file and imported that into the existing > > krb5.keytab > > > file using ktutil. I can see that now, klist -k shows a "host" principle > > > entry for this computer which was missing earlier. > > > > > > Also initialized the new keytab file using "kinit -k -t /etc/krb5.keytab > > > host/hostname.X.Y.local". I can see the service principal update after > > this > > > step in klist. > > > > > > But authentication using my AD account still fails with the following in > > > logs: > > > > > > > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sbus_dispatch] > > (0x4000): > > > dbus conn: 0x1666a60 > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sbus_dispatch] > > (0x4000): > > > Dispatching. > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sbus_message_handler] > > > (0x2000): Received SBUS method > > > org.freedesktop.sssd.dataprovider.getAccountInfo on path > > > /org/freedesktop/sssd/dataprovider > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > [sbus_get_sender_id_send] > > > (0x2000): Not a sysbus message, quit > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [be_get_account_info] > > > (0x0200): Got request for [0x1001][FAST > > > BE_REQ_USER][1][name=firstname.lastname] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [be_req_set_domain] > > > (0x0400): Changing request domain from [X.Y.local] to [X.Y.local] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > [sdap_id_op_connect_step] > > > (0x4000): reusing cached connection > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_search_user_next_base] (0x0400): Searching for users with base > > > [dc=X,dc=Y,dc=local] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_print_server] > > > (0x2000): Searching xxx.xxx.xxx.xxx > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > > [(&(sAMAccountName=firstname.lastname)(objectclass=user)( > > sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0))))][dc=X,dc=Y,dc=local]. > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > [unixUserPassword] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > [unixHomeDirectory] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > [userPrincipalName] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > > [userAccountControl] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 17 > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_op_add] (0x2000): > > > New operation 17 timeout 6 > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_process_result] > > > (0x2000): Trace: sh[0x166d2a0], connected[1], ops[0x1667a50], > > > ldap[0x1637f20] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_process_message] > > > (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_process_result] > > > (0x2000): Trace: sh[0x166d2a0], connected[1], ops[0x1667a50], > > > ldap[0x1637f20] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_process_message] > > > (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > > > errmsg set > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_op_destructor] > > > (0x2000): Operation 17 finished > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [generic_ext_search_handler] (0x4000): Request included referrals which > > > were ignored. > > > *(Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > [sdap_search_user_process] (0x0400): Search for users, returned 0 > > results.* > > > *(Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_get_users_done] > > > (0x0040): Failed to retrieve users* > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_id_op_done] > > > (0x4000): releasing operation connection > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [ldb] (0x4000): Added > > > timed event "ltdb_callback": 0x1692df0 > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [ldb] (0x4000): Added > > > timed event "ltdb_timeout": 0x1692120 > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [ldb] (0x4000): Running > > > timer event 0x1692df0 "ltdb_callback" > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [ldb] (0x4000): > > Destroying > > > timer event 0x1692120 "ltdb_timeout" > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [ldb] (0x4000): Ending > > > timer event 0x1692df0 "ltdb_callback" > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sysdb_search_by_name] > > > (0x0400): No such entry > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sysdb_search_groups] > > > (0x2000): Search groups with filter: > > > (&(objectclass=group)(ghost=firstname.lastname)) > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [ldb] (0x4000): Added > > > timed event "ltdb_callback": 0x1691210 > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [ldb] (0x4000): Added > > > timed event "ltdb_timeout": 0x167da00 > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [ldb] (0x4000): Running > > > timer event 0x1691210 "ltdb_callback" > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [ldb] (0x4000): > > Destroying > > > timer event 0x167da00 "ltdb_timeout" > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [ldb] (0x4000): Ending > > > timer event 0x1691210 "ltdb_callback" > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sysdb_search_groups] > > > (0x2000): No such entry > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sysdb_delete_user] > > > (0x0400): Error: 2 (No such file or directory) > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [acctinfo_callback] > > > (0x0100): Request processed. Returned 0,0,Success > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_process_result] > > > (0x2000): Trace: sh[0x166d2a0], connected[1], ops[(nil)], ldap[0x1637f20] > > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] [sdap_process_result] > > > (0x2000): Trace: ldap_result found nothing! > > > > > > > > > How to check further where it is failing? > > > > The log snippet just shows that this search: > > > > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > [(&(sAMAccountName=firstname.lastname)(objectclass=user)( > > sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0))))][dc=X,dc=Y,dc=local]. > > (Tue Feb 14 16:10:56 2017) [sssd[be[X.Y.local]]] > > > > didn't match any object on the AD side. I would test that if you kinit > > with the host principal and then ldapserch the DC manually using thy -Y > > GSSAPI switch, does the search yield any result? > > _______________________________________________ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
