2:43 a.m.
Hello
Could someone point me in the right direction with what is wrong here,
please? Thank you for any hint.
I want to make ldap authentication without kerberos ( access_provider =
ldap )
TLS/SSL encryption channel is fine, bind user is working, it can find my
testuser and the attributes, but simple bind for checking the password of
the found user is failing with Invalid credentials.
ldapsearch -LLL -h "10.10.10.10" -D "testuser(a)2FA.TEST" -w password -b
"CN=MyUser,CN=Users,DC=2FA,DC=TEST"
is returning the user but sssd fails.
This are the versions I'm using:
ii ldap-utils 2.4.31-1+nmu2 amd64
OpenLDAP utilities
ii libldap-2.4-2:amd64 2.4.31-1+nmu2
amd64 OpenLDAP libraries
ii libsasl2-modules-ldap:amd64
2.1.25.dfsg1-6+deb7u1 amd64 Cyrus SASL -
pluggable authentication modules (LDAP)
ii sssd-ldap 1.11.1-1 amd64
System Security Services Daemon -- LDAP back end
I've checked the pam module and it seams to make that is using the
userPrincipalName for authentication, is this correct?
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_cmd_authenticate] (0x0100):
entering pam_cmd_authenticate
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sss_parse_name_for_domains]
(0x0200): name 'testuser' matched without domain, user is testuser
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sss_parse_name_for_domains]
(0x0200): using default domain [(null)]
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
command: PAM_AUTHENTICATE
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
domain: not set
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100): user:
testuser
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
service: sshd
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100): ruser:
not set
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100): rhost:
192.168.1.1
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
authtok type: 1
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
newauthtok type: 0
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
cli_pid: 5354
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sss_ncache_check_str] (0x2000):
Checking negative cache for [NCE/USER/2FA.TEST/testuser]
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x417df0:3:testuser@2FA.TEST]
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sss_dp_get_account_msg]
(0x0400): *Creating request for [2FA.TEST][3][1][name=testuser]*
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sbus_add_timeout] (0x2000): 0xf2c1d0
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sss_dp_internal_get_send]
(0x0400): *Entering request [0x417df0:3:testuser@2FA.TEST]*
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sbus_remove_timeout] (0x2000):
0xf2c1d0
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sbus_dispatch] (0x4000): dbus
conn: 0xf28e30
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sbus_dispatch] (0x4000):
Dispatching.
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sss_dp_get_reply] (0x1000): *Got
reply from Data Provider - DP error code: 3 errno: 34 error message:
Init group lookup failed*
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_check_user_dp_callback]
(0x0040): Unable to get information from Data Provider
Error: 3, 34, Init group lookup failed
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_check_user_search] (0x0100):
Requesting info for [testuser(a)2FA.TEST]
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [ldb] (0x4000): Added timed event
"ltdb_callback": 0xf2dae0
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [ldb] (0x4000): Added timed event
"ltdb_timeout": 0xf380a0
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [ldb] (0x4000): Destroying timer
event 0xf380a0 "ltdb_timeout"
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [ldb] (0x4000): Ending timer
event 0xf2dae0 "ltdb_callback"
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_check_user_search] (0x0400):
Returning info for user [testuser(a)2FA.TEST]
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_initgr_cache_set] (0x2000):
[testuser] added to PAM initgroup cache
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_dp_send_req] (0x0100):
Sending request with the following data:
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
command: PAM_AUTHENTICATE
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
domain: 2FA.TEST
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100): user:
testuser
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
service: sshd
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100): ruser:
not set
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100): rhost:
192.168.1.1
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
authtok type: 1
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
newauthtok type: 0
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_print_data] (0x0100):
cli_pid: 5354
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sbus_add_timeout] (0x2000): 0xf29d40
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_dom_forwarder] (0x0100):
pam_dp_send_req returned 0
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x417df0:3:testuser@2FA.TEST]
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sbus_remove_timeout] (0x2000):
0xf29d40
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sbus_dispatch] (0x4000): dbus
conn: 0xf28e30
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [sbus_dispatch] (0x4000):
Dispatching.
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_dp_process_reply] (0x0100):
received: [7][2FA.TEST]
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_reply] (0x0200): pam_reply
called with result [7].
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [pam_reply] (0x0200): blen: 25
(Thu Dec 5 15:29:49 2013) [sssd[pam]] [reset_idle_timer] (0x4000): Idle
timer re-set for client [0xf31510][18]
(Thu Dec 5 15:29:52 2013) [sssd[pam]] [sbus_dispatch] (0x4000): dbus
conn: 0xf252b0
(Thu Dec 5 15:29:52 2013) [sssd[pam]] [sbus_dispatch] (0x4000):
Dispatching.
(Thu Dec 5 15:29:52 2013) [sssd[pam]] [sbus_message_handler] (0x4000):
Received SBUS method [ping]
(Thu Dec 5 15:29:54 2013) [sssd[pam]] [pam_initgr_cache_remove]
(0x2000): [testuser] removed from PAM initgroup cache
Below is the domain log:
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [get_server_status]
(0x1000): Status of server '2fa-ad.2FA.TEST' is 'working'
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [get_port_status]
(0x1000): Port status of port 636 for server '2fa-ad.2FA.TEST' is
'working'
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6
seconds
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [get_server_status]
(0x1000): Status of server '2fa-ad.2FA.TEST' is 'working'
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[be_resolve_server_process] (0x1000): Saving the first resolved server
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[be_resolve_server_process] (0x0200): Found address for server
2fa-ad.2FA.TEST: [10.10.10.10] TTL 7200
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [sdap_uri_callback]
(0x0400): Constructed uri 'ldaps://2fa-ad.2FA.TEST'
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [auth_resolve_done]
(0x2000): [ldaps://2fa-ad.2FA.TEST] is a secure channel. No need to run
START_TLS
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [sss_ldap_init_send]
(0x4000): Using file descriptor [22] for LDAP connection.
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [sss_ldap_init_send]
(0x0400): Setting 6 seconds timeout for connecting
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to
[ldaps://2fa-ad.2FA.TEST:636/??base] with fd [22].
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [fo_set_port_status]
(0x0100): Marking port 636 of server '2fa-ad.2FA.TEST' as 'working'
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[set_server_common_status] (0x0100): Marking server '2fa-ad.2FA.TEST' as
'working'
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [fo_set_port_status]
(0x0400): Marking port 636 of duplicate server '2fa-ad.2FA.TEST' as
'working'
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [ldb] (0x4000): Added
timed event "ltdb_callback": 0x16f1fe0
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [ldb] (0x4000): Added
timed event "ltdb_timeout": 0x16ee9a0
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [ldb] (0x4000):
Destroying timer event 0x16ee9a0 "ltdb_timeout"
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [ldb] (0x4000): Ending
timer event 0x16f1fe0 "ltdb_callback"
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[find_password_expiration_attributes] (0x4000): No password policy
requested.
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_send]
(0x0100): Executing simple bind as: CN=MyUser,CN=Users,DC=2FA,DC=TEST
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_send]
(0x2000): ldap simple bind sent, msgid = 1
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [sdap_process_result]
(0x2000): Trace: sh[0x16b3f40], connected[1], ops[0x16a9ad0],
ldap[0x16d63c0]
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [sdap_process_message]
(0x4000): Message type: [LDAP_RES_BIND]
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_done]
(0x1000): Server returned no controls.
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_done]
(0x0400):*B**ind result: Invalid credentials(49), 80090308: LdapErr:
DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e, v2580*
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [sdap_handle_release]
(0x2000): Trace: sh[0x16b3f40], connected[1], ops[(nil)],
ldap[0x16d63c0], destructor_lock[0], release_memory[0]
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[remove_connection_callback] (0x4000): Successfully removed connection
callback.
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 7, <NULL>)
[Success]
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[be_pam_handler_callback] (0x0100): Sending result [7][2FA.TEST]
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[be_pam_handler_callback] (0x0100): Sent result [7][2FA.TEST]
(Thu Dec 5 15:09:40 2013) [sssd[be[2FA.TEST]]] [sbus_dispatch]
(0x4000): dbus conn: 0x169b280
(Thu Dec 5 15:09:40 2013) [sssd[be[2FA.TEST]]] [sbus_dispatch]
(0x4000): Dispatching.
(Thu Dec 5 15:09:40 2013) [sssd[be[2FA.TEST]]] [sbus_message_handler]
(0x4000): Received SBUS method [ping]
--
Dan Cândea
Does God Play Dice?
3:01 a.m.
On Fri, Dec 06, 2013 at 10:43:58AM +0200, Dan Candea wrote:
Hello
Could someone point me in the right direction with what is wrong
here, please? Thank you for any hint.
I want to make ldap authentication without kerberos (
access_provider = ldap )
TLS/SSL encryption channel is fine, bind user is working, it can
find my testuser and the attributes, but simple bind for checking
the password of
the found user is failing with Invalid credentials.
ldapsearch -LLL -h "10.10.10.10" -D "testuser(a)2FA.TEST" -w password
-b "CN=MyUser,CN=Users,DC=2FA,DC=TEST"
is returning the user but sssd fails.
This are the versions I'm using:
ii ldap-utils 2.4.31-1+nmu2 amd64
OpenLDAP utilities
ii libldap-2.4-2:amd64 2.4.31-1+nmu2
amd64 OpenLDAP libraries
ii libsasl2-modules-ldap:amd64 2.1.25.dfsg1-6+deb7u1
amd64 Cyrus SASL - pluggable authentication modules (LDAP)
ii sssd-ldap 1.11.1-1 amd64
System Security Services Daemon -- LDAP back end
I've checked the pam module and it seams to make that is using the
userPrincipalName for authentication, is this correct?
No, that's just internal user identifier that's passed around.
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_send]
(0x0100): Executing simple bind as:
CN=MyUser,CN=Users,DC=2FA,DC=TEST
The bind DN is here.
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_send]
(0x2000): ldap simple bind sent, msgid = 1
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[sdap_process_result] (0x2000): Trace: sh[0x16b3f40], connected[1],
ops[0x16a9ad0], ldap[0x16d63c0]
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_BIND]
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_done]
(0x1000): Server returned no controls.
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_done]
(0x0400):*B**ind result: Invalid credentials(49), 80090308: LdapErr:
DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e,
v2580*
(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
[sdap_handle_release] (0x2000): Trace: sh[0x16b3f40], connected[1],
ops[(nil)], ldap[0x16d63c0], destructor_lock[0], release_memory[0]
Normally Invalid credentials means wrong password, also "data 52e" means
ERROR_LOGON_FAILURE, which also suspects wrong password.
When you were testing the bind with ldapseach, are you sure you used the
same server as SSSD did?
3:13 a.m.
On 12/06/2013 11:01 AM, Jakub Hrozek wrote:
On Fri, Dec 06, 2013 at 10:43:58AM +0200, Dan Candea wrote:
> Hello
>
> Could someone point me in the right direction with what is wrong
> here, please? Thank you for any hint.
>
> I want to make ldap authentication without kerberos (
> access_provider = ldap )
> TLS/SSL encryption channel is fine, bind user is working, it can
> find my testuser and the attributes, but simple bind for checking
> the password of
> the found user is failing with Invalid credentials.
>
> ldapsearch -LLL -h "10.10.10.10" -D "testuser(a)2FA.TEST" -w
password
> -b "CN=MyUser,CN=Users,DC=2FA,DC=TEST"
> is returning the user but sssd fails.
>
> This are the versions I'm using:
> ii ldap-utils 2.4.31-1+nmu2 amd64
> OpenLDAP utilities
> ii libldap-2.4-2:amd64 2.4.31-1+nmu2
> amd64 OpenLDAP libraries
> ii libsasl2-modules-ldap:amd64 2.1.25.dfsg1-6+deb7u1
> amd64 Cyrus SASL - pluggable authentication modules (LDAP)
> ii sssd-ldap 1.11.1-1 amd64
> System Security Services Daemon -- LDAP back end
>
>
> I've checked the pam module and it seams to make that is using the
> userPrincipalName for authentication, is this correct?
No, that's just internal user identifier that's passed around.
> (Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_send]
> (0x0100): Executing simple bind as:
> CN=MyUser,CN=Users,DC=2FA,DC=TEST
The bind DN is here.
> (Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_send]
> (0x2000): ldap simple bind sent, msgid = 1
> (Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
> [sdap_process_result] (0x2000): Trace: sh[0x16b3f40], connected[1],
> ops[0x16a9ad0], ldap[0x16d63c0]
> (Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
> [sdap_process_message] (0x4000): Message type: [LDAP_RES_BIND]
> (Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_done]
> (0x1000): Server returned no controls.
> (Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_done]
> (0x0400):*B**ind result: Invalid credentials(49), 80090308: LdapErr:
> DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e,
> v2580*
> (Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
> [sdap_handle_release] (0x2000): Trace: sh[0x16b3f40], connected[1],
> ops[(nil)], ldap[0x16d63c0], destructor_lock[0], release_memory[0]
Normally Invalid credentials means wrong password, also "data 52e" means
ERROR_LOGON_FAILURE, which also suspects wrong password.
When you were testing the bind with ldapseach, are you sure you used the
same server as SSSD did?
Yes, copy paste. But ldapsearch works only with usertest(a)2FA.TEST format.
SUCCESS: ldapsearch -LLL -h "10.10.10.10" -D "testuser(a)2FA.TEST" -w
password -b "CN=MyUser,CN=Users,DC=2FA,DC=TEST"
FAIL: ldapsearch -LLL -h "10.10.10.10" -D "testuser" -w password -b
"CN=MyUser,CN=Users,DC=2FA,DC=TEST"
What username format is sssd passing to ldap server? Where is this
information in debug log?
Thx
--
Dan Cândea
Does God Play Dice?
3 a.m.
On Fri, Dec 06, 2013 at 11:13:16AM +0200, Dan Candea wrote:
On 12/06/2013 11:01 AM, Jakub Hrozek wrote:
>On Fri, Dec 06, 2013 at 10:43:58AM +0200, Dan Candea wrote:
>>Hello
>>
>>Could someone point me in the right direction with what is wrong
>>here, please? Thank you for any hint.
>>
>>I want to make ldap authentication without kerberos (
>>access_provider = ldap )
>>TLS/SSL encryption channel is fine, bind user is working, it can
>>find my testuser and the attributes, but simple bind for checking
>>the password of
>>the found user is failing with Invalid credentials.
>>
>>ldapsearch -LLL -h "10.10.10.10" -D "testuser(a)2FA.TEST" -w
password
>>-b "CN=MyUser,CN=Users,DC=2FA,DC=TEST"
>>is returning the user but sssd fails.
>>
>>This are the versions I'm using:
>>ii ldap-utils 2.4.31-1+nmu2 amd64
>>OpenLDAP utilities
>>ii libldap-2.4-2:amd64 2.4.31-1+nmu2
>>amd64 OpenLDAP libraries
>>ii libsasl2-modules-ldap:amd64 2.1.25.dfsg1-6+deb7u1
>>amd64 Cyrus SASL - pluggable authentication modules (LDAP)
>>ii sssd-ldap 1.11.1-1 amd64
>>System Security Services Daemon -- LDAP back end
>>
>>
>>I've checked the pam module and it seams to make that is using the
>>userPrincipalName for authentication, is this correct?
>No, that's just internal user identifier that's passed around.
>
>>(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_send]
>>(0x0100): Executing simple bind as:
>>CN=MyUser,CN=Users,DC=2FA,DC=TEST
>The bind DN is here.
>
>>(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_send]
>>(0x2000): ldap simple bind sent, msgid = 1
>>(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
>>[sdap_process_result] (0x2000): Trace: sh[0x16b3f40], connected[1],
>>ops[0x16a9ad0], ldap[0x16d63c0]
>>(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
>>[sdap_process_message] (0x4000): Message type: [LDAP_RES_BIND]
>>(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_done]
>>(0x1000): Server returned no controls.
>>(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]] [simple_bind_done]
>>(0x0400):*B**ind result: Invalid credentials(49), 80090308: LdapErr:
>>DSID-0C0903C5, comment: AcceptSecurityContext error, data 52e,
>>v2580*
>>(Thu Dec 5 15:09:32 2013) [sssd[be[2FA.TEST]]]
>>[sdap_handle_release] (0x2000): Trace: sh[0x16b3f40], connected[1],
>>ops[(nil)], ldap[0x16d63c0], destructor_lock[0], release_memory[0]
>Normally Invalid credentials means wrong password, also "data 52e" means
>ERROR_LOGON_FAILURE, which also suspects wrong password.
>
>When you were testing the bind with ldapseach, are you sure you used the
>same server as SSSD did?
>
Yes, copy paste. But ldapsearch works only with usertest(a)2FA.TEST format.
SUCCESS: ldapsearch -LLL -h "10.10.10.10" -D "testuser(a)2FA.TEST" -w
password -b "CN=MyUser,CN=Users,DC=2FA,DC=TEST"
FAIL: ldapsearch -LLL -h "10.10.10.10" -D "testuser" -w password -b
"CN=MyUser,CN=Users,DC=2FA,DC=TEST"
What username format is sssd passing to ldap server? Where is this
information in debug log?
When performing the LDAP password bind, the user's full DN is used to
bind. According to the logs you sent earlier, this would be
CN=MyUser,CN=Users,DC=2FA,DC=TEST
btw the server seems to be AD. Is there a reason to use LDAP
authentication with AD and not Kerberos authentication?
3:54 a.m.
On 12/09/2013 11:00 AM, Jakub Hrozek wrote:
When performing the LDAP password bind, the user's full DN is
used to
bind. According to the logs you sent earlier, this would be
CN=MyUser,CN=Users,DC=2FA,DC=TEST
btw the server seems to be AD. Is there a reason to use LDAP
authentication with AD and not Kerberos authentication?
I've tested with the
ldapsearch with the full DN and it worked, but not
from sssd.
I've googled more and i think is related to the anonymous bind to AD, so
because is insecure
I switched to kerberos, but again while kinit is working both for bind
user and for user I tried to authenticate,
in sssd is not working.
First I received "Preauthentication failed", which I disabled from AD,
but now I receive
"Decrypt integrity check failed"
--
Dan Cândea
Does God Play Dice?
4:08 a.m.
On Mon, Dec 09, 2013 at 11:54:59AM +0200, Dan Candea wrote:
On 12/09/2013 11:00 AM, Jakub Hrozek wrote:
>When performing the LDAP password bind, the user's full DN is used to
>bind. According to the logs you sent earlier, this would be
>CN=MyUser,CN=Users,DC=2FA,DC=TEST
>
>btw the server seems to be AD. Is there a reason to use LDAP
>authentication with AD and not Kerberos authentication?
I've tested with the ldapsearch with the full DN and it worked, but
not from sssd.
I've googled more and i think is related to the anonymous bind to
AD, so because is insecure
I switched to kerberos, but again while kinit is working both for
bind user and for user I tried to authenticate,
in sssd is not working.
First I received "Preauthentication failed", which I disabled from
AD,
Don't disable preauthentication in production environments, please..
but now I receive
"Decrypt integrity check failed"
Decrypt integrity check failed means wrong password.
I'm really stumped by this, SSSD does the equivalent of kinit.. If you
bump the debug_level to 10, the logfile /var/log/sssd/krb5_child.log would
contain low-level tracing information from libkrb5. You can obtain the same
information from kinit by running "KRB5_TRACE=/dev/stderr kinit user@DOMAIN"
and compare the two.
4:09 a.m.
On Mon, Dec 09, 2013 at 11:54:59AM +0200, Dan Candea wrote:
On 12/09/2013 11:00 AM, Jakub Hrozek wrote:
>When performing the LDAP password bind, the user's full DN is used to
>bind. According to the logs you sent earlier, this would be
>CN=MyUser,CN=Users,DC=2FA,DC=TEST
>
>btw the server seems to be AD. Is there a reason to use LDAP
>authentication with AD and not Kerberos authentication?
I've tested with the ldapsearch with the full DN and it worked, but
not from sssd.
I've googled more and i think is related to the anonymous bind to
AD, so because is insecure
I switched to kerberos, but again while kinit is working both for
bind user and for user I tried to authenticate,
in sssd is not working.
First I received "Preauthentication failed", which I disabled from
AD, but now I receive
"Decrypt integrity check failed"
The typical reason for those two messages is a wrong password as well.
Can you check if you have additional whitespaces in the sssd.conf line
with your password? Or if you are using a keytab to authenticate, can
you check if the keytab is still valid?
HTH
bye,
Sumit
--
Dan Cândea
Does God Play Dice?
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
4:15 a.m.
On 12/09/2013 12:09 PM, Sumit Bose wrote:
The typical reason for those two messages is a wrong password as
well.
Can you check if you have additional whitespaces in the sssd.conf line
with your password? Or if you are using a keytab to authenticate, can
you check if the keytab is still valid?
I'm getting wrong password for the bind
user? Not for the user I tried
to authenticate?
I'm using keytab, and password is valid for both users
I'll try to do a debug like Jakub Hrozek recommended, and I'll get back
with the results.
Thx
--
Dan Cândea
Does God Play Dice?
4:25 a.m.
ldapauth is the user used for AD bind
testuser is the user that fails while doing ssh -> pam_sss(sshd:auth):
received for user testuser: 7 (Authentication failure)
So which one fails from the logs below? I would say is the testuser's
password, the same one I'm putting in kinit where it works.
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [main] (0x0400):
krb5_child started.
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [unpack_buffer]
(0x1000): total buffer size: [123]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [unpack_buffer]
(0x0100): cmd [241] uid [10000] gid [10000] validate [false] enterprise
principal [false] offline [false] UPN [testuser(a)2FA.TEST]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [unpack_buffer]
(0x0100): ccname: [FILE:/tmp/krb5cc_10000_XXXXXX] keytab: [/etc/krb5.keytab]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [k5c_setup]
(0x0100): SSSD_KRB5_RENEWABLE_LIFETIME is set to [1d]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [k5c_setup]
(0x0100): SSSD_KRB5_LIFETIME is set to [1h]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [false]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [k5c_setup_fast]
(0x0100): SSSD_KRB5_LIFETIME is set to [1h]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [k5c_setup_fast]
(0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [ldapauth]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[find_principal_in_keytab] (0x4000): Trying to find principal
ldapauth(a)2FA.TEST in keytab.
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [match_principal]
(0x1000): Principal matched to the sample (ldapauth(a)2FA.TEST).
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.604514: Retrieving
ldapauth(a)2FA.TEST -> krbtgt/2FA.TEST(a)2FA.TEST from
FILE:/var/lib/sss/db/fast_ccache_2FA.TEST with result: 0/Success
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[check_fast_ccache] (0x0200): FAST TGT is still valid.
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [main] (0x0400):
Will perform online auth
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [tgt_req_child]
(0x1000): Attempting to get a TGT
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [get_and_save_tgt]
(0x0400): Attempting kinit for realm [2FA.TEST]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605000: Getting
initial credentials for testuser(a)2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605161: FAST armor
ccache: FILE:/var/lib/sss/db/fast_ccache_2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605262: Retrieving
ldapauth(a)2FA.TEST ->
krb5_ccache_conf_data/fast_avail/krbtgt\/2FA.TEST\@2FA.TEST(a)X-CACHECONF:
from FILE:/var/lib/sss/db/fast_ccache_2FA.TEST with result:
-1765328243/Matching credential not found
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605391: Sending
request (171 bytes) to 2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605496: Resolving
hostname 2fa-ad.2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605791: Sending
initial UDP request to dgram 10.52.13.190:88
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.607384: Received
answer from dgram 10.52.13.190:88
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.677781: Response
was not from master KDC
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.677933: Salt
derived from principal: 2FA.TESTtestuser
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.677953: Getting AS
key, salt "2FA.TESTtestuser", params ""
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678158: AS key
obtained from gak_fct: rc4-hmac/9C81
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678303: Retrying
AS request with master KDC
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678379: Getting
initial credentials for testuser(a)2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678501: FAST armor
ccache: FILE:/var/lib/sssdb/fast_ccache_2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678737: Retrieving
ldapauth(a)2FA.TEST ->
krb5_ccache_conf_data/fast_avail/krbtgt\/2FA.TEST\@2FA.TEST(a)X-CACHECONF:
from FILE:/var/lib/sss/db/fast_ccache_2FA.TEST with result:
-1765328243/Matching credential not found
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678843: Sending
request (171 bytes) to 2FA.TEST (master)
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [get_and_save_tgt]
(0x0020): 918: [-1765328353][Decrypt integrity check failed]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [map_krb5_error]
(0x0020): 979: [-1765328353][Decrypt integrity check failed]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[pack_response_packet] (0x2000): response packet size: [4]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [k5c_send_data]
(0x4000): Response sent.
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [main] (0x0400):
krb5_child completed successfully
--
Dan Cândea
Does God Play Dice?
6:34 a.m.
On 12/09/2013 12:25 PM, Dan Candea wrote:
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605000: Getting
initial credentials for testuser(a)2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605161: FAST
armor ccache: FILE:/var/lib/sss/db/fast_ccache_2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605262:
Retrieving ldapauth(a)2FA.TEST ->
krb5_ccache_conf_data/fast_avail/krbtgt\/2FA.TEST\@2FA.TEST(a)X-CACHECONF:
from FILE:/var/lib/sss/db/fast_ccache_2FA.TEST with result:
-1765328243/Matching credential not found
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605391: Sending
request (171 bytes) to 2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605496:
Resolving hostname 2fa-ad.2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.605791: Sending
initial UDP request to dgram 10.52.13.190:88
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.607384: Received
answer from dgram 10.52.13.190:88
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.677781: Response
was not from master KDC
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.677933: Salt
derived from principal: 2FA.TESTtestuser
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.677953: Getting
AS key, salt "2FA.TESTtestuser", params ""
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678158: AS key
obtained from gak_fct: rc4-hmac/9C81
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678303:
*Retrying AS request with master KDC *
Why sssd is doing this retry?
Here is how kinit is doing
KRB5_TRACE=/dev/stderr kinit testuser
[5332] 1386592069.283264: Getting initial credentials for testuser(a)2FA.TEST
[5332] 1386592069.283720: Sending request (150 bytes) to 2FA.TEST
[5332] 1386592069.283838: Resolving hostname 2fa-ad.2FA.TEST
[5332] 1386592069.284143: Sending initial UDP request to dgram
10.52.13.190:88
[5332] 1386592069.289908: Received answer from dgram 10.52.13.190:88
[5332] 1386592069.335244: Response was not from master KDC
[5332] 1386592069.335375: Salt derived from principal: 2FA.TESTtestuser
[5332] 1386592069.335438: Getting AS key, salt "2FA.TESTtestuser", params
""
Password for testuser(a)2FA.TEST:
[5332] 1386592072.864966: AS key obtained from gak_fct: rc4-hmac/53BB
[5332] 1386592072.865226: Decrypted AS reply; session key is: rc4-hmac/8DBC
[5332] 1386592072.865349: FAST negotiation: unavailable
[5332] 1386592072.865491: Initializing FILE:/tmp/krb5cc_0 with default
princ testuser(a)2FA.TEST
[5332] 1386592072.866066: Removing testuser(a)2FA.TEST ->
krbtgt/2FA.TEST(a)2FA.TEST from FILE:/tmp/krb5cc_0
[5332] 1386592072.866184: Storing testuser(a)2FA.TEST ->
krbtgt/2FA.TEST(a)2FA.TEST in FILE:/tmp/krb5cc_0
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678379: Getting
initial credentials for testuser(a)2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678501: FAST
armor ccache: FILE:/var/lib/sssdb/fast_ccache_2FA.TEST
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678737:
Retrieving ldapauth(a)2FA.TEST ->
krb5_ccache_conf_data/fast_avail/krbtgt\/2FA.TEST\@2FA.TEST(a)X-CACHECONF:
from FILE:/var/lib/sss/db/fast_ccache_2FA.TEST with result:
-1765328243/Matching credential not found
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[sss_child_krb5_trace_cb] (0x4000): [1335] 1386584323.678843: Sending
request (171 bytes) to 2FA.TEST (master)
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[get_and_save_tgt] (0x0020): 918: [-1765328353][Decrypt integrity
check failed]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [map_krb5_error]
(0x0020): 979: [-1765328353][Decrypt integrity check failed]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]]
[pack_response_packet] (0x2000): response packet size: [4]
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [k5c_send_data]
(0x4000): Response sent.
(Mon Dec 9 10:18:43 2013) [[sssd[krb5_child[1335]]]] [main] (0x0400):
krb5_child completed successfully
--
Dan Cândea
Does God Play Dice?
7:39 a.m.
Hi
Doring kerberos autentication, why the credentials are like
testuser\@2FA.TEST(a)2FA.TEST ?
shouldn't be just testuser(a)2FA.TEST
(Mon Dec 9 13:34:59 2013) [[sssd[krb5_child[8887]]]]
[sss_child_krb5_trace_cb] (0x4000): [8887] 1386596099.972715: Getting
initial credentials for vsw_dic\@2FA.TEST(a)2FA.TEST
--
Dan Cândea
Does God Play Dice?
9:40 a.m.
On (09/12/13 15:39), Dan Candea wrote:
Hi
Doring kerberos autentication, why the credentials are like
testuser\@2FA.TEST(a)2FA.TEST ?
shouldn't be just testuser(a)2FA.TEST
(Mon Dec 9 13:34:59 2013) [[sssd[krb5_child[8887]]]]
[sss_child_krb5_trace_cb] (0x4000): [8887] 1386596099.972715: Getting
initial credentials for vsw_dic\@2FA.TEST(a)2FA.TEST
It looks like enterprise principal.
Could you try to disable krb5_use_enterprise_principal, because default
value is true with ad provider. (details are in manual page: man sssd-ad)
LS
9:49 a.m.
On 12/09/2013 05:40 PM, Lukas Slebodnik wrote:
On (09/12/13 15:39), Dan Candea wrote:
> Hi
>
> Doring kerberos autentication, why the credentials are like
> testuser\@2FA.TEST(a)2FA.TEST ?
> shouldn't be just testuser(a)2FA.TEST
>
> (Mon Dec 9 13:34:59 2013) [[sssd[krb5_child[8887]]]]
> [sss_child_krb5_trace_cb] (0x4000): [8887] 1386596099.972715: Getting
> initial credentials for testuser\@2FA.TEST(a)2FA.TEST
>
It looks like enterprise principal.
Could you try to disable krb5_use_enterprise_principal, because default
value is true with ad provider. (details are in manual page: man sssd-ad)
LS
Yes, that was it. Now I'm back to "Decrypt integrity check failed"
which
is invalid password even if
the password is good.
krb5_server = 2fa-ad.2FA.TEST
krb5_realm = 2FA.TEST
krb5_auth_timeout = 15
krb5_canonicalize = true
krb5_fast_principal = ldapauth
krb5_use_fast = try
krb5_lifetime = 1h
krb5_renewable_lifetime = 1d
The kerberos AD user that I use for bind (ldapauth) needs a special AD
right so it can check the testuser password?
When I tried with simple bind (auth_access=ldap) I was stuck in the same
point, so it could be an AD issue?
thx
--
Dan Cândea
Does God Play Dice?
10:17 a.m.
On Mon, Dec 09, 2013 at 05:49:14PM +0200, Dan Candea wrote:
On 12/09/2013 05:40 PM, Lukas Slebodnik wrote:
>On (09/12/13 15:39), Dan Candea wrote:
>>Hi
>>
>>Doring kerberos autentication, why the credentials are like
>>testuser\@2FA.TEST(a)2FA.TEST ?
>>shouldn't be just testuser(a)2FA.TEST
>>
>>(Mon Dec 9 13:34:59 2013) [[sssd[krb5_child[8887]]]]
>>[sss_child_krb5_trace_cb] (0x4000): [8887] 1386596099.972715: Getting
>>initial credentials for testuser\@2FA.TEST(a)2FA.TEST
>>
>It looks like enterprise principal.
>
>Could you try to disable krb5_use_enterprise_principal, because default
>value is true with ad provider. (details are in manual page: man sssd-ad)
>
>LS
Yes, that was it. Now I'm back to "Decrypt integrity check failed"
which is invalid password even if
the password is good.
krb5_server = 2fa-ad.2FA.TEST
krb5_realm = 2FA.TEST
krb5_auth_timeout = 15
krb5_canonicalize = true
krb5_fast_principal = ldapauth
this is wrong. If you use krb5_fast_principal the value has to be a
Kerberos principal (something(a)MY.REALM) and it must match an entry in
you keytab. Typically the host/your.host.name(a)YOUR.REALM entry from the
keytab is used and in the case you do not have to set
krb5_fast_principal at all. So I would recommend to remove this option
as well, maybe even disable FAST at all for initial testing.
HTH
bye,
Sumit
krb5_use_fast = try
krb5_lifetime = 1h
krb5_renewable_lifetime = 1d
The kerberos AD user that I use for bind (ldapauth) needs a special
AD right so it can check the testuser password?
When I tried with simple bind (auth_access=ldap) I was stuck in the
same point, so it could be an AD issue?
thx
--
Dan Cândea
Does God Play Dice?
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
10:49 a.m.
On 12/09/2013 06:17 PM, Sumit Bose wrote:
this is wrong. If you use krb5_fast_principal the value has to be a
Kerberos principal (something(a)MY.REALM) and it must match an entry in
you keytab. Typically thehost/your.host.name(a)YOUR.REALM entry from the
keytab is used and in the case you do not have to set
krb5_fast_principal at all. So I would recommend to remove this option
as well, maybe even disable FAST at all for initial testing.
Ok, I removed the
fast, but still no luck with ssh, partially working
with login
Dec 9 16:44:48 test-2fa login[2680]: pam_unix(login:auth): check pass;
user unknown
Dec 9 16:44:48 test-2fa login[2680]: pam_unix(login:auth):
authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser=
rhost=
Dec 9 16:44:48 test-2fa login[2680]: pam_sss(login:auth):
authentication success; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser=
rhost= user=testuser
Dec 9 16:44:48 test-2fa login[2680]: pam_unix(login:account): could not
identify user (from getpwnam(testuser))
Dec 9 16:44:48 test-2fa login[2680]: Authentication failure
Dec 9 16:45:11 test-2fa sshd[19149]: Invalid user testuser from
10.10.10.100
Dec 9 16:45:11 test-2fa sshd[19149]: input_userauth_request: invalid
user testuser [preauth]
Dec 9 16:45:16 test-2fa sshd[19149]: pam_unix(sshd:auth): check pass;
user unknown
Dec 9 16:45:16 test-2fa sshd[19149]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.62.102.170
Dec 9 16:45:16 test-2fa sshd[19149]: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.62.102.170
user=testuser
Dec 9 16:45:16 test-2fa sshd[19149]: pam_sss(sshd:auth): received for
user testuser: 7 (Authentication failure)
Dec 9 16:45:18 test-2fa sshd[19149]: Failed password for invalid user
testuser from 10.62.102.170 port 34281 ssh2
--
Dan Cândea
Does God Play Dice?
11 a.m.
On (06/12/13 10:43), Dan Candea wrote:
Hello
Could someone point me in the right direction with what is wrong
here, please? Thank you for any hint.
I want to make ldap authentication without kerberos ( access_provider
= ldap )
TLS/SSL encryption channel is fine, bind user is working, it can find
my testuser and the attributes, but simple bind for checking the
password of
the found user is failing with Invalid credentials.
ldapsearch -LLL -h "10.10.10.10" -D "testuser(a)2FA.TEST" -w password
-b "CN=MyUser,CN=Users,DC=2FA,DC=TEST"
is returning the user but sssd fails.
This are the versions I'm using:
ii ldap-utils 2.4.31-1+nmu2 amd64
OpenLDAP utilities
ii libldap-2.4-2:amd64 2.4.31-1+nmu2
amd64 OpenLDAP libraries
ii libsasl2-modules-ldap:amd64 2.1.25.dfsg1-6+deb7u1
amd64 Cyrus SASL - pluggable authentication modules (LDAP)
ii sssd-ldap 1.11.1-1 amd64
System Security Services Daemon -- LDAP back end
I would suggest to configure sssd against AD with relamd.
debian >= jessie and ubuntu >= raring contain this package.
http://packages.debian.org/jessie/realmd
http://packages.ubuntu.com/raring/realmd
LS
8:57 a.m.
On 12/09/2013 07:00 PM, Lukas Slebodnik wrote:
I would suggest to configure sssd against AD with relamd.
debian >= jessie and ubuntu >= raring contain this package.
http://packages.debian.org/jessie/realmd
http://packages.ubuntu.com/raring/realmd
LS
Thx, this gave me a new config to start-up, and finally it worked.
Any workaround until this https://fedorahosted.org/sssd/ticket/1560
is solved?
--
Dan Cândea
Does God Play Dice?
9:21 a.m.
On Tue, Dec 10, 2013 at 04:57:47PM +0200, Dan Candea wrote:
On 12/09/2013 07:00 PM, Lukas Slebodnik wrote:
>I would suggest to configure sssd against AD with relamd.
>debian >= jessie and ubuntu >= raring contain this package.
>
>http://packages.debian.org/jessie/realmd
>http://packages.ubuntu.com/raring/realmd
>
>LS
Thx, this gave me a new config to start-up, and finally it worked.
Any workaround until this https://fedorahosted.org/sssd/ticket/1560
is solved?
Can you try setting:
ldap_user_ssh_public_key = sshPublicKey
(or whatever schema you use)
9:40 a.m.
On 12/10/2013 05:21 PM, Jakub Hrozek wrote:
On Tue, Dec 10, 2013 at 04:57:47PM +0200, Dan Candea wrote:
> On 12/09/2013 07:00 PM, Lukas Slebodnik wrote:
>> I would suggest to configure sssd against AD with relamd.
>> debian >= jessie and ubuntu >= raring contain this package.
>>
>> http://packages.debian.org/jessie/realmd
>> http://packages.ubuntu.com/raring/realmd
>>
>> LS
> Thx, this gave me a new config to start-up, and finally it worked.
>
> Any workaround until this https://fedorahosted.org/sssd/ticket/1560
> is solved?
Can you try setting:
ldap_user_ssh_public_key = sshPublicKey
I have like this
[domain/2FA.TEST]
ad_server = 2fa-ad.2FA.TEST
ad_domain = 2FA.TEST
krb5_realm = 2FA.TEST
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%d/%u
access_provider = ad
krb5_use_enterprise_principal = True
debug_level = 10
enumerate = False
ldap_referrals = False
ldap_id_mapping = True
min_id = 1000
ad_access_filter = memberOf=CN=Linux-Admins,OU=Security
Groups,DC=2FA,DC=TEST
ldap_user_search_filer = memberOf=CN=Linux-Admins,OU=Security
Groups,DC=2FA,DC=TEST
*ldap_user_ssh_public_key = sshPublicKey*
but in the sssd_ldap log I can see
[sssd[be[2FA.TEST]]] [sdap_get_generic_ext_step] (0x1000): Requesting
attrs: [sshPublicKey]
.....
[sssd[be[2FA.TEST]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey
is not available for [testuser].
and in the ldapsearch i can see the attribute
sshPublicKey: ssh-rsa AAAAB.....
Thx
--
Dan Cândea
Does God Play Dice?
9:47 a.m.
On 12/10/2013 05:40 PM, Dan Candea wrote:
On 12/10/2013 05:21 PM, Jakub Hrozek wrote:
> On Tue, Dec 10, 2013 at 04:57:47PM +0200, Dan Candea wrote:
>> On 12/09/2013 07:00 PM, Lukas Slebodnik wrote:
>>> I would suggest to configure sssd against AD with relamd.
>>> debian >= jessie and ubuntu >= raring contain this package.
>>>
>>> http://packages.debian.org/jessie/realmd
>>> http://packages.ubuntu.com/raring/realmd
>>>
>>> LS
>> Thx, this gave me a new config to start-up, and finally it worked.
>>
>> Any workaround until thishttps://fedorahosted.org/sssd/ticket/1560
>> is solved?
> Can you try setting:
> ldap_user_ssh_public_key = sshPublicKey
>
I have like this
[domain/2FA.TEST]
ad_server = 2fa-ad.2FA.TEST
ad_domain = 2FA.TEST
krb5_realm = 2FA.TEST
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%d/%u
access_provider = ad
krb5_use_enterprise_principal = True
debug_level = 10
enumerate = False
ldap_referrals = False
ldap_id_mapping = True
min_id = 1000
ad_access_filter = memberOf=CN=Linux-Admins,OU=Security
Groups,DC=2FA,DC=TEST
ldap_user_search_filer = memberOf=CN=Linux-Admins,OU=Security
Groups,DC=2FA,DC=TEST
*ldap_user_ssh_public_key = sshPublicKey*
but in the sssd_ldap log I can see
[sssd[be[2FA.TEST]]] [sdap_get_generic_ext_step] (0x1000): Requesting
attrs: [sshPublicKey]
.....
[sssd[be[2FA.TEST]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey
is not available for [testuser].
and in the ldapsearch i can see the attribute
sshPublicKey: ssh-rsa AAAAB.....
Thx
--
Dan Cândea
Does God Play Dice?
on sssd restart I can't see the
[dp_get_options] (0x0400): Option ldap_user_ssh_public_key has
shouldn't it be there?
--
Dan Cândea
Does God Play Dice?
9:52 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/10/2013 10:40 AM, Dan Candea wrote:
On 12/10/2013 05:21 PM, Jakub Hrozek wrote:
> On Tue, Dec 10, 2013 at 04:57:47PM +0200, Dan Candea wrote:
>> On 12/09/2013 07:00 PM, Lukas Slebodnik wrote:
>>> I would suggest to configure sssd against AD with relamd.
>>> debian >= jessie and ubuntu >= raring contain this package.
>>>
>>> http://packages.debian.org/jessie/realmd
>>> http://packages.ubuntu.com/raring/realmd
>>>
>>> LS
>> Thx, this gave me a new config to start-up, and finally it
>> worked.
>>
>> Any workaround until this
>> https://fedorahosted.org/sssd/ticket/1560 is solved?
> Can you try setting: ldap_user_ssh_public_key = sshPublicKey
>
I have like this
[domain/2FA.TEST] ad_server = 2fa-ad.2FA.TEST ad_domain = 2FA.TEST
krb5_realm = 2FA.TEST realmd_tags = manages-system
joined-with-adcli cache_credentials = True id_provider = ad
krb5_store_password_if_offline = True default_shell = /bin/bash
ldap_id_mapping = True use_fully_qualified_names = False
fallback_homedir = /home/%d/%u access_provider = ad
krb5_use_enterprise_principal = True
debug_level = 10 enumerate = False ldap_referrals = False
ldap_id_mapping = True min_id = 1000 ad_access_filter =
memberOf=CN=Linux-Admins,OU=Security Groups,DC=2FA,DC=TEST
ldap_user_search_filer = memberOf=CN=Linux-Admins,OU=Security
Groups,DC=2FA,DC=TEST *ldap_user_ssh_public_key = sshPublicKey*
but in the sssd_ldap log I can see [sssd[be[2FA.TEST]]]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs:
[sshPublicKey] ..... [sssd[be[2FA.TEST]]]
[sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available
for [testuser].
and in the ldapsearch i can see the attribute sshPublicKey: ssh-rsa
AAAAB.....
How are you running the ldapsearch? This public key needs to be
accessible via the host account on the machine. You can test this with:
kinit -k host/FQDN(a)2FA.TEST
(substitute the proper hostname for FQDN)
And then run 'ldapsearch -Y GSSAPI <other arguments>'
This will simulate the search that SSSD is running. My suspicion is
that the ACL on the sshPublicKey attribute is visible to your user
account but not to the SSSD host account. This will confirm that.
If so, you need to have the AD admin grant access to that attribute
for host accounts.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKnOLsACgkQeiVVYja6o6MghgCZAdbld3aZRMYZW5IpNvsXpA4g
0ZYAoKZojyBfuavaI0ejmEC00o5rZhQB
=WtFg
-----END PGP SIGNATURE-----
4:15 a.m.
On 12/10/2013 05:52 PM, Stephen Gallagher wrote:
How are you running the ldapsearch? This public key needs to be
accessible via the host account on the machine. You can test this with:
kinit -khost/FQDN(a)2FA.TEST
(substitute the proper hostname for FQDN)
And then run 'ldapsearch -Y GSSAPI <other arguments>'
This will simulate the search that SSSD is running. My suspicion is
that the ACL on the sshPublicKey attribute is visible to your user
account but not to the SSSD host account. This will confirm that.
If so, you need to have the AD admin grant access to that attribute
for host accounts.
I just did that test and ldapsearch returns sshPublicKey, but
sssd says
that the attribute is not available
kinit -k host/infr-test-2fa.2fa.test(a)2FA.TEST
klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/infr-test-2fa.2fa.test(a)2FA.TEST
Valid starting Expires Service principal
12/11/2013 10:10:28 12/11/2013 20:10:28 krbtgt/2FA.TEST(a)2FA.TEST
renew until 12/12/2013 10:10:54
12/11/2013 10:10:32 12/11/2013 20:10:28 ldap/2fa-ad.2fa.test@
renew until 12/12/2013 10:10:54
12/11/2013 10:10:32 12/11/2013 20:10:28 ldap/2fa-ad.2fa.test(a)2FA.TEST
renew until 12/12/2013 10:10:54
ldapsearch -Y GSSAPI -h 2fa-ad.2fa.test -b DC=2FA,DC=TEST -s sub
"(uid=testuser)" sshPublicKey
SASL/GSSAPI authentication started
SASL username: host/infr-test-2fa.2fa.test(a)2FA.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <DC=2FA,DC=TEST> with scope subtree
# filter: (uid=testuser)
# requesting: sshPublicKey
#
dn: CN=MyUser,CN=Users,DC=2FA,DC=TEST
sshPublicKey: ssh-rsa AAAA........ testuser@hostname
# search reference
ref: ldap://ForestDnsZones.2FA.TEST/DC=ForestDnsZones,DC=2FA,DC=TEST
# search reference
ref: ldap://DomainDnsZones.2FA.TEST/DC=DomainDnsZones,DC=2FA,DC=TEST
# search reference
ref: ldap://2FA.TEST/CN=Configuration,DC=2FA,DC=TEST
# search result
search: 4
result: 0 Success
# numResponses: 5
# numEntries: 1
# numReferences: 3
--
Dan Cândea
Does God Play Dice?
8:50 a.m.
On Wed, 2013-12-11 at 12:15 +0200, Dan Candea wrote:
On 12/10/2013 05:52 PM, Stephen Gallagher wrote:
> How are you running the ldapsearch? This public key needs to be
> accessible via the host account on the machine. You can test this with:
>
> kinit -khost/FQDN(a)2FA.TEST
>
> (substitute the proper hostname for FQDN)
>
> And then run 'ldapsearch -Y GSSAPI <other arguments>'
>
> This will simulate the search that SSSD is running. My suspicion is
> that the ACL on the sshPublicKey attribute is visible to your user
> account but not to the SSSD host account. This will confirm that.
>
> If so, you need to have the AD admin grant access to that attribute
> for host accounts.
I just did that test and ldapsearch returns sshPublicKey, but sssd says
that the attribute is not available
This is probably because the latest sssd versions use the Global Catalog
as LDAP server in preference.
Arbitrary attributes are not synced to the GC tree, so you either need
to prevent SSSD from reading from the GC or change the AD configuration
to sync that attribute to the GC.
HTH,
Simo.
kinit -k host/infr-test-2fa.2fa.test(a)2FA.TEST
klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/infr-test-2fa.2fa.test(a)2FA.TEST
Valid starting Expires Service principal
12/11/2013 10:10:28 12/11/2013 20:10:28 krbtgt/2FA.TEST(a)2FA.TEST
renew until 12/12/2013 10:10:54
12/11/2013 10:10:32 12/11/2013 20:10:28 ldap/2fa-ad.2fa.test@
renew until 12/12/2013 10:10:54
12/11/2013 10:10:32 12/11/2013 20:10:28 ldap/2fa-ad.2fa.test(a)2FA.TEST
renew until 12/12/2013 10:10:54
ldapsearch -Y GSSAPI -h 2fa-ad.2fa.test -b DC=2FA,DC=TEST -s sub
"(uid=testuser)" sshPublicKey
SASL/GSSAPI authentication started
SASL username: host/infr-test-2fa.2fa.test(a)2FA.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <DC=2FA,DC=TEST> with scope subtree
# filter: (uid=testuser)
# requesting: sshPublicKey
#
dn: CN=MyUser,CN=Users,DC=2FA,DC=TEST
sshPublicKey: ssh-rsa AAAA........ testuser@hostname
# search reference
ref: ldap://ForestDnsZones.2FA.TEST/DC=ForestDnsZones,DC=2FA,DC=TEST
# search reference
ref: ldap://DomainDnsZones.2FA.TEST/DC=DomainDnsZones,DC=2FA,DC=TEST
# search reference
ref: ldap://2FA.TEST/CN=Configuration,DC=2FA,DC=TEST
# search result
search: 4
result: 0 Success
# numResponses: 5
# numEntries: 1
# numReferences: 3
--
Simo Sorce * Red Hat, Inc * New York
8:56 a.m.
On Wed, Dec 11, 2013 at 09:50:51AM -0500, Simo Sorce wrote:
Arbitrary attributes are not synced to the GC tree, so you either
need
to prevent SSSD from reading from the GC or change the AD configuration
to sync that attribute to the GC.
btw I have a local patch with a new option to disable GC lookups of
anyone wished to do so. (part of a fix for #2152)
9:16 a.m.
On 12/11/2013 04:50 PM, Simo Sorce wrote:
This is probably because the latest sssd versions use the Global
Catalog
as LDAP server in preference.
Arbitrary attributes are not synced to the GC tree, so you either need
to prevent SSSD from reading from the GC or change the AD configuration
to sync that attribute to the GC.
Thank you for the tip :)
It worked after the GC synchronization.
--
Dan Cândea
Does God Play Dice?
9:22 a.m.
New subject: ldap authentication [SOLVED]
On 12/11/2013 04:50 PM, Simo Sorce wrote:
This is probably because the latest sssd versions use the Global
Catalog
as LDAP server in preference.
Arbitrary attributes are not synced to the GC tree, so you either need
to prevent SSSD from reading from the GC or change the AD configuration
to sync that attribute to the GC.
Solved by putting in AD to the sshPublicKey
attribute to replicate to GC
--
Dan Cândea
Does God Play Dice?
3789
days inactive
3794
days old
sssd-users@lists.fedorahosted.org
25 comments
6 participants
participants (6)
-
Dan Candea -
Jakub Hrozek -
Lukas Slebodnik -
Simo Sorce -
Stephen Gallagher -
Sumit Bose