>On Fri, 20 Mar 2015, Sumit Bose wrote:
>>On Fri, Mar 20, 2015 at 11:44:43AM +0100, Bobby Prins wrote:
>>> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote:
>>> >> Hi there,
>>> >>
>>> >> I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA 
>>> >> setup (described here: 
>>> >> http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be 
>>> >> able to autenticate AIX 7.1 clients against an AD domain using LDAP. 
>>> >> After the trust was created all seems to work well on the freeIPA 
>>> >> server. I can also do a lookup of AD users and groups on an AIX test 
>>> >> server.
>>> >>
>>> >> But as soon as I want to log in on the AIX system I get an SSSD error on 
>>> >> the freeIPA server in krb5_child.log (debug_level = 10):
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key 
>>> >> obtained for encrypted timestamp: aes256-cts/2F5D
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted 
>>> >> timestamp (for 1426778442.525165): plain 
>>> >> 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 
>>> >> 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth 
>>> >> module encrypted_timestamp (2) (flags=1) returned: 0/Success
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced 
>>> >> preauth for next request: 2
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending 
>>> >> request (238 bytes) to EXAMPLE.CORP
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving 
>>> >> hostname dct020.example.corp.
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending 
>>> >> initial UDP request to dgram 192.168.143.1:88
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received 
>>> >> answer from dgram 192.168.143.1:88
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response 
>>> >> was not from master KDC
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received 
>>> >> error from KDC: -1765328360/Preauthentication failed
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth 
>>> >> tryagain input types: 16, 14, 19, 2
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying 
>>> >> AS request with master KDC
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting 
>>> >> initial credentials for bpr...@example.corp
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending 
>>> >> request (160 bytes) to EXAMPLE.CORP (master)
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] 
>>> >> [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed]
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [map_krb5_error] 
>>> >> (0x0020): 1040: [-1765328360][Preauthentication failed]
>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [k5c_send_data] 
>>> >> (0x0200): Received error code 1432158214
>>> >>
>>> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit bpr...@example.corp':
>>> >> [12299] 1426773524.361785: AS key obtained for encrypted timestamp: 
>>> >> aes256-cts/B997
>>> >> [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): 
>>> >> plain 301AA011180F32303135303331393133353834345AA1050203043C4F, 
>>> >> encrypted 
>>> >> ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0
>>> >> [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) 
>>> >> (flags=1) returned: 0/Success
>>> >> [12299] 1426773524.361880: Produced preauth for next request: 2
>>> >> [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP
>>> >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp.
>>> >> [12299] 1426773524.363841: Sending initial UDP request to dgram 
>>> >> 192.168.141.1:88
>>> >> [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88
>>> >> [12299] 1426773524.368482: Response was not from master KDC
>>> >> [12299] 1426773524.368500: Received error from KDC: -1765328332/Response 
>>> >> too big for UDP, retry with TCP
>>> >> [12299] 1426773524.368506: Request or response is too big for UDP; 
>>> >> retrying with TCP
>>> >> [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP 
>>> >> (tcp only)
>>> >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp.
>>> >> [12299] 1426773524.370056: Initiating TCP connection to stream 
>>> >> 192.168.143.5:88
>>> >> [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88
>>> >> [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88
>>> >> [12299] 1426773524.384237: Response was not from master KDC
>>> >> [12299] 1426773524.384263: Processing preauth types: 19
>>> >> [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt 
>>> >> "EXAMPLE.CORPBPrins", params ""
>>> >> [12299] 1426773524.384275: Produced preauth for next request: (empty)
>>> >> [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997
>>> >> [12299] 1426773524.384329: Decrypted AS reply; session key is: 
>>> >> rc4-hmac/39AB
>>> >> [12299] 1426773524.384333: FAST negotiation: unavailable
>>> >> [12299] 1426773524.384357: Initializing 
>>> >> KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ 
>>> >> bpr...@example.corp
>>> >> [12299] 1426773524.384400: Removing bpr...@example.corp -> 
>>> >> krbtgt/example.c...@example.corp from 
>>> >> KEYRING:persistent:0:krb_ccache_rhX3V4v
>>> >> [12299] 1426773524.384407: Storing bpr...@example.corp -> 
>>> >> krbtgt/example.c...@example.corp in 
>>> >> KEYRING:persistent:0:krb_ccache_rhX3V4v
>>> >> [12299] 1426773524.384469: Storing config in 
>>> >> KEYRING:persistent:0:krb_ccache_rhX3V4v for 
>>> >> krbtgt/example.c...@example.corp: pa_type: 2
>>> >> [12299] 1426773524.384484: Removing bpr...@example.corp -> 
>>> >> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP@X-CACHECONF:
>>> >>  from KEYRING:persistent:0:krb_ccache_rhX3V4v
>>> >> [12299] 1426773524.384492: Storing bpr...@example.corp -> 
>>> >> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP@X-CACHECONF:
>>> >>  in KEYRING:persistent:0:krb_ccache_rhX3V4v
>>> >>
>>> >> Any ideas?
>>> >
>>> >Can you log in to the IPA server as this user? If yes I would assume
>>> >that the password gets garbled somewhere on the way from AIX through the
>>> >IPA machinery to SSSD. Does the password contain some special characters
>>> >which some LDAP processing calls might want the escape?
>>> >
>>> >bye,
>>> >Sumit
>>> >
>>> Yes, I can login with the account on the IPA server without any problems. I 
>>> tried it with different password to rule out problems with special 
>>> characters. Finally I did a tcpdump on the IPA server. The AIX server sends 
>>> the word 'INCORRECT' to the IPA server instead of the password. So I guess 
>>> I have to do some more configuration checks on the AIX server.
>>
>>Thank you for the feedback.
>>
>>Just a wild guess, since you were able to see anything in the tcpdump I
>>guess an unencrypted connection is used. Maybe AIX prevents that the
>>password is send via a clear text connection?
>It is openssh behavior. It sends INCORRECT line as part of the password
>when there is no valid shell for that user to login.
>
>OpenSSH validates content of 'struct passwd' returned for the user,
>including checks on whether shell is there as an executable file. This
>check fails and user is considered 'invalid'. Still, OpenSSH competes
>PAM authentication, making sure the password field is filled with
>specially constructed string "\b\n\r\177INCORRECT", to ensure there is
>registered failed login attempt.
>
>-- 
>/ Alexander Bokovoy
Wow, thanks for that! If I do a lsuser/ldapsearch on the AIX host the 
shell/loginShell is missing for AD users. The admin IPA user has this attribute 
set and I can log in with that account. Can this be solved on the IPA server?

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

Reply via email to