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(a)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 <jhrozek(a)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(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org