How does one 'force' adbindproxy to use Centrify's Kerberos executables?
Environment:
AIX 7.1 TL5 being used as a SAMBA file server.
Windows 7 clients.
Issue:
Inaccessible SAMBA shares after reboot.
Notes:
(During this entire excercise users were able to successfully authenticate with their AD credentials in order to gain access to an AIX shell and run programs. The DC Express serivice(s) seem to work properly.)
There have been times when after multiple adleave's, adjoins's, full CentrifyDC Express uninstall/reinstalls with adbindproxy.pl included, the shares DO become available and work properly. Shares are browsable from Windows explorer. The smb.conf file can be updated normally. Shares can be added/removed normally, too.
Until a reboot happens. Afterwards, we get the enter username password window at the clients that doesn't go away because Samba is getting authentication errors.
[2018/01/03 09:28:37.460974, 3] ../source3/auth/token_util.c:317(create_local_nt_token_from_info3) Failed to finalize nt token [2018/01/03 09:28:37.460996, 1] ../source3/auth/auth_generic.c:172(auth3_generate_session_info_pac) Failed to map kerberos pac to server info (NT_STATUS_UNSUCCESSFUL)
Come to find out our AIX 7 install has it's own IBM JAVA-flavored Kerberos which I believe is confusing/interfiering with Centrify Express' Kerberos. Resulting in inaccessible SAMBA shares.
All commands were run as root.
#AIX'S KERBEROS bash-4.3# which kinit /usr/java5/jre/bin/kinit
#CENTRIFY'S KERBEROS
bash-4.3# /usr/share/centrifydc/kerberos/bin/kinit
All the information that I found asks to run kinit, klist, or kdestroy from the prompt. In our case, doing so runs the AIX version of the commands, and they error out.
bash-4.3# kinit testuser
Password for testuser@PSA.LOCAL:
{visible password characters}
com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0
message: java.security.InvalidKeyException: Illegal key size
Not to mention consistently running into these errors once the shares become unavailable. Not sure if they are related somehow.
#re-running adbindproxy.pl
... Updating smb.conf with Centrify recommended settings... Connection failed: NT_STATUS_INVALID_PARAMETER Get Domain SID failed. Please try again with authentication and a valid DC. ... Done. Failed to change computer password in AD domain psa.local /usr/sbin/adkeytab fails with: Error: Computer failed to change its own password Adjust the privilege settings for 'server1' or retry with a more privileged principal. Failed: Change Password: Default Key Tab
I did not find a way to change/renew the password unless it was leaving the domain and rejoining it.
However...
Running the executables from within the Centrify directory produces the results displayed in the information online.
bash-4.3# /usr/share/centrifydc/kerberos/bin/kinit testuser
Password for testuser@PSA.LOCAL:
{NON-visible password characters}
bash-4.3#
bash-4.3#
bash-4.3#
bash-4.3# /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0
Default principal: testuser@PSA.LOCAL
Valid starting Expires Service principal
01/03/18 10:18:33 01/03/18 20:18:33 krbtgt/PSA.LOCAL@PSA.LOCAL
renew until 01/04/18 10:18:27
Also, we have a centrify-kcm service isn't launched on server startup.
What is centrify-kcm? What is it used for?