One user is not able to login to any endpoint. When trying to log in, unab always throws
Error code 17, Attempt rejected by the native environment
Other users have no issues on same servers
UNAB is working in partial integration mode. When a local password is set for the user experiencing the problem he is able to log in as expected, and the /uid/gid/shell/home path is correctly set
Searching for the user in /var/log/secure, yields the following errors
[email protected]:~# cat /var/log/secure | grep xxxx
Jun 14 13:00:02 unabex sshd[18760]: UNAB handle parameters - user: xxxx, service: sshd, got pwd: yes, got old_pwd: no, conv_ptr: not null
Jun 14 13:00:02 unabex sshd[18760]: UNAB in pam_agent_preauth_check user: xxxx
Jun 14 13:00:02 unabex sshd[18760]: UNAB in pam_agent_send_login_audit user: xxxx
Jun 14 13:00:02 unabex sshd[18760]: UNAB pam_agent_send_login_audit user:agopa ret code:0
Jun 14 13:00:02 unabex sshd[18760]: UNAB RETURNING pam_sm_authenticate, user: xxxx, ret code: 25 (The return value should be ignored by PAM dispatch)
But at the same time, running
/opt/CA/uxauth/bin/uxconsole -krb -init xxxx
results in no error, but
./uxchecklogin -s sshd -u xxx
produces an error in the following module
pam_authenticate() returned PAM_AUTH_ERR
CA PAMSC UNAB 14.1, PIM UNAB 14.0, PIM UNAB 12.9 and ControlMinder UNAB 12.8SP1
The problem occurs if the account in question has the "No Kerberos preauthentication required" attribute set, which weakens authentication (it requests the use of discontinued Kerberos 4 protocol).
UNAB's pam_uxauth module legitimately disallows such a user to log in since that compromises the whole idea of having secure authentication.
One can easily identify/check for this problem from the endpoint by doing the following:
1. obtain a ticket via uxconsole -krb -init xxxx
2. dump user account using uxconsole -ldap -search '(&(objectClass=user)(cn=xxxx*))'
Below is an example. The attribute to check is userAccountControl;
dn: CN=xxxx,CN=Users,DC=myunab,DC=com
objectClass[1]: top
objectClass[2]: person
objectClass[3]: organizationalPerson
objectClass[4]: user
cn: xxxx
givenName: xxxx
distinguishedName: CN=xxxx,CN=Users,DC=myunab,DC=com
instanceType: 4
whenCreated: 20210625132640.0Z
whenChanged: 20210625133746.0Z
displayName: xxxx
uSNCreated: 343045
uSNChanged: 343105
name: test4
objectGUID: {EFFF0DF2-A7E1-46D4-98E0-EFBFEB60C028}
userAccountControl: 0x410200 (UF_DONT_REQUIRE_PREAUTH | UF_DONT_EXPIRE_PASSWD | UF_NORMAL_ACCOUNT)
badPwdCount: 0
codePage: 0
The user experiencing the problem must be edited in Active Directory and the "Do not require Kerberos preauthentication" checbox should be cleared in the properties page for the account
Kerberos Pre-Authentication is a security feature which offers protection against password-guessing attacks. The AS request identifies the client to the KDC in Plaintext. If Kerberos Pre-Authentication is enabled, a Timestamp will be encrypted using the user's password hash as an encryption key. If the KDC reads a valid time when using the user's password hash, which is available in the Microsoft Active Directory, to decrypt the Timestamp, the KDC knows that request isn't a replay of a previous request.
Without Kerberos Pre-Authentication a malicious attacker can directly send a dummy request for authentication. The KDC will return an encrypted TGT and the attacker can brute force it offline. Upon checking the KDC logs, nothing will be seen except a single request for a TGT. When Kerberos timestamp Kerberos Pre-Authentication is enforced, the attacker cannot directly ask the KDCs for the encrypted material to Brute-Force offline.