FreeNAS Domain Failure on AD

DustinB3403

@scottalanmiller I'd ask that the FreeNAS be removed from the domain and then have the AD computer record removed as well.

Once that is done, reboot the NAS, and rejoin it to the domain.

Or at least confirm what process was done.

scottalanmiller

I'm waiting on my access to be restored after a reboot. No responses on email now.

scottalanmiller

I'm back in, and yes the computer account was blown away before rejoining.

scottalanmiller

The behaviour is that it shows the share but you can't actually connect in and browse the share. You see them listed. But when you hit them to open them it asks for a username and password. And those, of course, don't work.

DustinB3403

@scottalanmiller said in FreeNAS Domain Failure on AD:

The behaviour is that it shows the share but you can't actually connect in and browse the share. You see them listed. But when you hit them to open them it asks for a username and password. And those, of course, don't work.

So the FreeNAS isn't accepting other domain users as they access the share? Is that correct? Has anyone attempted to access the share using a local account to the NAS?

scottalanmiller

@DustinB3403 said in FreeNAS Domain Failure on AD:

@scottalanmiller said in FreeNAS Domain Failure on AD:

The behaviour is that it shows the share but you can't actually connect in and browse the share. You see them listed. But when you hit them to open them it asks for a username and password. And those, of course, don't work.

So the FreeNAS isn't accepting other domain users as they access the share? Is that correct? Has anyone attempted to access the share using a local account to the NAS?

Yes, a local NAS account will work.

DustinB3403

@scottalanmiller said in FreeNAS Domain Failure on AD:

@DustinB3403 said in FreeNAS Domain Failure on AD:

@scottalanmiller said in FreeNAS Domain Failure on AD:

The behaviour is that it shows the share but you can't actually connect in and browse the share. You see them listed. But when you hit them to open them it asks for a username and password. And those, of course, don't work.

So the FreeNAS isn't accepting other domain users as they access the share? Is that correct? Has anyone attempted to access the share using a local account to the NAS?

Yes, a local NAS account will work.

Ok so we know the share is operable.. . . . . I likely missed this, but what version of FreeNAS is this?

DustinB3403

Just as a simple test, from the NAS are you able to ping the domain controller using the DC's name?

scottalanmiller

@DustinB3403 said in FreeNAS Domain Failure on AD:

@scottalanmiller said in FreeNAS Domain Failure on AD:

@DustinB3403 said in FreeNAS Domain Failure on AD:

@scottalanmiller said in FreeNAS Domain Failure on AD:

The behaviour is that it shows the share but you can't actually connect in and browse the share. You see them listed. But when you hit them to open them it asks for a username and password. And those, of course, don't work.

So the FreeNAS isn't accepting other domain users as they access the share? Is that correct? Has anyone attempted to access the share using a local account to the NAS?

Yes, a local NAS account will work.

Ok so we know the share is operable.. . . . . I likely missed this, but what version of FreeNAS is this?

Latest. Only installed weeks ago.

scottalanmiller

@DustinB3403 said in FreeNAS Domain Failure on AD:

Just as a simple test, from the NAS are you able to ping the domain controller using the DC's name?

Yes.

scottalanmiller

Current errors from log.smbd

[2017/02/09 17:52:59.841916,  1] ../source3/librpc/crypto/gse.c:497(gse_get_server_auth_token)
  gss_accept_sec_context failed with [ Miscellaneous failure (see text): Failed to find cifs/[email protected](kvno 17) in keytab MEMORY:cifs_srv_keytab (aes256-cts-hmac-sha1-96)]
[2017/02/09 17:52:59.841973,  1] ../auth/gensec/spnego.c:541(gensec_spnego_parse_negTokenInit)
  SPNEGO(gse_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE

DustinB3403

@scottalanmiller is only 1 users account attempting to access this share?

Just checking here, the error message seems to indicate that the domain user account is expired or locked.

So the followup question, do you have access to the DC to determine if this user account is active and unlocked?

scottalanmiller

And this works...

# wbinfo -t
checking the trust secret for domain DOMAIN via RPC calls succeeded

scottalanmiller

@DustinB3403 said in FreeNAS Domain Failure on AD:

@scottalanmiller is only 1 users account attempting to access this share?

Many

DustinB3403

@scottalanmiller Are there AD account expirations (not password expiration, but actually the user account) in this domain?

scottalanmiller

It can't be user accounts. All users, hundreds of them, all stopped working at the same time.

DustinB3403

From Microsoft

Clients’ credentials have been revoked while getting initial credentials
Application/Function: kinit
Potential Causes and Solution: Can indicate that the user's account is locked or expired (account expired, not password expired).
UNIX System Log File (syslog) Error Messages
CROND[11772]: GSSAPI Error: The context has expired (No error)
Application/Function: Message appearing in syslog related to Kerberos authentication for the LDAP authorization connection to the Active Directory server.
Potential Cause and Solution: The Kerberos credential used to make the LDAP connection to the Active Directory server has expired and has not or could not be renewed. Confirm that the cron job to acquire the credential for the proxy/service user is correct. Confirm that the key table containing the stored key for the proxy/service user is correct. Attempt to manually acquire a credential for the proxy/service user using this command (where /etc/proxy.keytab is the key table containing the key for the proxy user and proxy/service is the name of the proxy user):
/usr/bin/kinit -k -t /etc/proxy.keytab proxy/service
(Only applicable to 2B open source solutions)

DustinB3403

@DustinB3403 said in FreeNAS Domain Failure on AD:

From Microsoft

Clients’ credentials have been revoked while getting initial credentials
Application/Function: kinit
Potential Causes and Solution: Can indicate that the user's account is locked or expired (account expired, not password expired).
UNIX System Log File (syslog) Error Messages
CROND[11772]: GSSAPI Error: The context has expired (No error)
Application/Function: Message appearing in syslog related to Kerberos authentication for the LDAP authorization connection to the Active Directory server.
Potential Cause and Solution: The Kerberos credential used to make the LDAP connection to the Active Directory server has expired and has not or could not be renewed. Confirm that the cron job to acquire the credential for the proxy/service user is correct. Confirm that the key table containing the stored key for the proxy/service user is correct. Attempt to manually acquire a credential for the proxy/service user using this command (where /etc/proxy.keytab is the key table containing the key for the proxy user and proxy/service is the name of the proxy user):
/usr/bin/kinit -k -t /etc/proxy.keytab proxy/service
(Only applicable to 2B open source solutions)

So did someone update the domain account used in FreeNAS with a new password?

scottalanmiller

@DustinB3403 said in FreeNAS Domain Failure on AD:

@DustinB3403 said in FreeNAS Domain Failure on AD:

From Microsoft

Clients’ credentials have been revoked while getting initial credentials
Application/Function: kinit
Potential Causes and Solution: Can indicate that the user's account is locked or expired (account expired, not password expired).
UNIX System Log File (syslog) Error Messages
CROND[11772]: GSSAPI Error: The context has expired (No error)
Application/Function: Message appearing in syslog related to Kerberos authentication for the LDAP authorization connection to the Active Directory server.
Potential Cause and Solution: The Kerberos credential used to make the LDAP connection to the Active Directory server has expired and has not or could not be renewed. Confirm that the cron job to acquire the credential for the proxy/service user is correct. Confirm that the key table containing the stored key for the proxy/service user is correct. Attempt to manually acquire a credential for the proxy/service user using this command (where /etc/proxy.keytab is the key table containing the key for the proxy user and proxy/service is the name of the proxy user):
/usr/bin/kinit -k -t /etc/proxy.keytab proxy/service
(Only applicable to 2B open source solutions)

So did someone update the domain account used in FreeNAS with a new password?

Seems unlikely since it was just joined in the middle of testing. How could that be? That would have made sense for the initial problem. But not now, right?

DustinB3403

@scottalanmiller While you can join a system to a domain using any domain admin credentials, but within freeNAS you have a field for set credentials to use for domain functions.

Can you confirm those credentials? Domain Account Name and Domain Account Password

https://doc.freenas.org/9.3/freenas_directoryservice.html

Edit: of course, I assume the join and removal is all taking place from within FreeNAS.... so ignore me....