On 9 March 2017 at 10:29, John Beranek <j...@redux.org.uk> wrote:
> So, an update on this - I left the server for a day, and Samba has
> stopped authenticating. Samba log says:
>
> [2017/03/09 10:21:48.814799,  3] smbd/process.c:1609(process_smb)
>   Transaction 9 of length 2670 (0 toread)
> [2017/03/09 10:21:48.814904,  3] smbd/process.c:1414(switch_message)
>   switch message SMBsesssetupX (pid 20958) conn 0x0
> [2017/03/09 10:21:48.814945,  3] smbd/sesssetup.c:1347(reply_sesssetup_and_X)
>   wct=12 flg2=0xc807
> [2017/03/09 10:21:48.814973,  2] smbd/sesssetup.c:1293(setup_new_vc_session)
>   setup_new_vc_session: New VC == 0, if NT4.x compatible we would
> close all old resources.
> [2017/03/09 10:21:48.815008,  3]
> smbd/sesssetup.c:1074(reply_sesssetup_and_X_spnego)
>   Doing spnego session setup
> [2017/03/09 10:21:48.815040,  3]
> smbd/sesssetup.c:1116(reply_sesssetup_and_X_spnego)
>   NativeOS=[] NativeLanMan=[] PrimaryDomain=[]
> [2017/03/09 10:21:48.815093,  3] smbd/sesssetup.c:662(reply_spnego_negotiate)
>   reply_spnego_negotiate: Got secblob of size 2524
> [2017/03/09 10:21:48.817915,  3]
> libads/kerberos_verify.c:297(ads_keytab_verify_ticket)
>   libads/kerberos_verify.c:297: krb5_rd_req failed for all 40 matched
> keytab principals
> [2017/03/09 10:21:48.817969,  3] 
> libads/kerberos_verify.c:638(ads_verify_ticket)
>   libads/kerberos_verify.c:638: krb5_rd_req with auth failed (Success)
> [2017/03/09 10:21:48.818024,  1] smbd/sesssetup.c:344(reply_spnego_kerberos)
>   Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
>
> sssd shows that adcli has been run:
>
> (Wed Mar  8 16:18:26 2017) [sssd[be[AD]]]
> [ad_machine_account_password_renewal_done] (0x1000): --- adcli output
> start---
>  * Found realm in keytab: EXAMPLE.COM
>  * Found computer name in keytab: SERVER
>  * Found service principal in keytab: host/SERVER
>  * Found service principal in keytab: host/server.example.com
>  * Found host qualified name in keytab: host/server.example.com
>  * Found service principal in keytab: RestrictedKrbHost/SERVER
>  * Found service principal in keytab: RestrictedKrbHost/server.example.com
>  * Using fully qualified name: server.example.com
>  * Using domain name: example.com
>  * Calculated computer account name from fqdn: SERVER
>  * Using domain realm: example.com
>  * Sending netlogon pings to domain controller: cldap://10.20.30.40
>  * Received NetLogon info from: dc1.example.com
>  * Wrote out krb5.conf snippet to
> /tmp/adcli-krb5-m5MrZa/krb5.d/adcli-krb5-conf-FYuKkI
>  * Authenticated as default/reset computer account: SERVER
>  * Looked up short domain name: EXAMPLE
>  * Using fully qualified name: server.example.com
>  * Using domain name: example.com
>  * Using computer account name: SERVER
>  * Using domain realm: example.com
>  * Using fully qualified name: server.example.com
>  * Enrolling computer name: SERVER
>  * Generated 120 character computer password
>  * Using keytab: FILE:/etc/krb5.keytab
>  * Found computer account for SERVER$ at:
> CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com
>  * Retrieved kvno '32' for computer account in directory:
> CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com
>  * Password not too old, no change needed
>  * Modifying computer account: userAccountControl
>  ! Couldn't set userAccountControl on computer account:
> CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com: Insufficient
> access
>  * Updated existing computer account:
> CN=SERVER,OU=Non-Windows,OU=Servers,DC=example,DC=com
> ---adcli output end---
>
> So, adcli updated the keytab, but Samba auth still stopped working?

It seems a bit worse than this though, as sssd itself is upset too:

Mar  9 12:05:19 server [sssd[krb5_child[32221]]]: Key version number
for principal in key table is incorrect
Mar  9 12:05:19 server [sssd[krb5_child[32221]]]: Key version number
for principal in key table is incorrect

I'm going to try to clear the SSSD databases to see if that helps.

John
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

Reply via email to