Project

General

Profile

Bug #24496

get [MiddlewareError: b'Active Directory failed to reload.'] when trying to bind freenas to AD

Added by Fernando Regino over 3 years ago. Updated about 3 years ago.

Status:
Closed: User Config Issue
Priority:
No priority
Assignee:
Timur Bakeyev
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

here is the error below

Jun 13 02:38:58 pernnas.regino ActiveDirectory: /usr/sbin/service ix-pam quietstart
Jun 13 02:38:59 pernnas.regino ActiveDirectory: /usr/sbin/service ix-cache quietstart &
Jun 13 02:39:10 pernnas.regino uwsgi: [middleware.exceptions:36] [MiddlewareError: b'Active Directory failed to reload.']

noticed that I would lose connection to AD after upgrading to RC4 I am not able to bind the freenas install to AD and cannot see the users and groups within the permissions screen. now I cannot access none of my files since I cannot bind AD to freenas

History

#1 Updated by Fernando Regino over 3 years ago

  • File debug-pernnas-20170613024902.txz added

#2 Updated by John Hixson over 3 years ago

  • Status changed from Unscreened to Screened
  • Target version set to 11.0-U1

#3 Updated by John Hixson over 3 years ago

  • Assignee changed from John Hixson to Timur Bakeyev

Timur, can you take a look at this?

#4 Updated by Fernando Regino over 3 years ago

John Hixson wrote:

Timur, can you take a look at this?

I also would like to add that I was able to bind freenas to my current AD environment. No changes were made to my AD environment that I know off. The rest of the PC's and servers still continue to receive auth services from the 2 Domain controllers

#5 Updated by Timur Bakeyev over 3 years ago

Hi, Fernando!

As I understand, you have problems with the binding FreeNAS to your AD? So, that's functionality provided by winbindd daemon.

from the /var/db/samba4/log.winbindd I see:

[2017/06/13 02:48:51.983990,  0] ../source3/librpc/crypto/gse.c:529(gse_get_client_auth_token)
  gse_get_client_auth_token: gss_init_sec_context failed with [ Miscellaneous failure (see text): Clock skew too great](2529638949)
[2017/06/13 02:48:51.984066,  1] ../auth/gensec/spnego.c:569(gensec_spnego_parse_negTokenInit)
  SPNEGO(gse_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE
[2017/06/13 02:48:51.984141,  1] ../source3/winbindd/winbindd_cm.c:1113(cm_prepare_connection)
  authenticated session setup to DC2.regino.us using REGINO\PERNNAS$ failed with NT_STATUS_LOGON_FAILURE
[2017/06/13 02:48:51.984274,  1] ../source3/winbindd/winbindd_cm.c:1253(cm_prepare_connection)
  Failed to prepare SMB connection to DC2.regino.us: NT_STATUS_LOGON_FAILURE

that login to the domain fails and that most probable reason is that local time on your FreeNAS box is way out of sync with your AD servers. AD uses Kerberos for it's authentication and it's known to be very sensitive to the time synchronization.

NTP is probably not capable to set the time on your box correctly as it's way out of sync with the normal time.

Can you try to set time on FreeNAS box manually and make sure that your NTP service is on and synchronizing? It also could be wise to use your AD servers as the NTP servers in System -> General -> NTP Servers.

And, just in case check your authentication parameters to AD.

#6 Updated by Timur Bakeyev over 3 years ago

You can also run the following command in the FN shell/over SSH:

# ntpq -p

to see how is your time differs from the servers. Also, you can try:
# ntpdate -q your.ad.server

to see what is the time difference.

#7 Updated by Timur Bakeyev over 3 years ago

  • Seen in changed from Unspecified to 11.0-RC4

#9 Updated by Fernando Regino over 3 years ago

Timur Bakeyev wrote:

You can also run the following command in the FN shell/over SSH:

[...]
to see how is your time differs from the servers. Also, you can try:

[...]
to see what is the time difference.

that was the problem, after verifying the time source was viable, I was able to join the domain

[root@pernnas ~]# ntpdate -q dc2.regino.us
server 192.168.29.14, stratum 2, offset 297.226114, delay 0.04158
14 Jun 21:52:27 ntpdate40754: step time server 192.168.29.14 offset 297.226114
sec
[root@pernnas ~]# ntpdate -q domainc.regino.us
server 192.168.29.15, stratum 1, offset 297.244287, delay 0.04137
14 Jun 21:52:56 ntpdate40759: step time server 192.168.29.15 offset 297.244287
sec
[root@pernnas ~]#
[root@pernnas ~]#

#10 Updated by Timur Bakeyev over 3 years ago

  • Status changed from Screened to Closed: User Config Issue
  • % Done changed from 0 to 100

Great, I'm closing this ticket then.

#11 Updated by Vaibhav Chauhan about 3 years ago

  • Target version changed from 11.0-U1 to 11.0-U2

#12 Updated by Vaibhav Chauhan about 3 years ago

  • Target version changed from 11.0-U2 to 11.0-U3

#13 Updated by Dru Lavigne about 3 years ago

  • Target version changed from 11.0-U3 to N/A

#14 Updated by Dru Lavigne about 3 years ago

  • File deleted (debug-pernnas-20170613024902.txz)

#15 Updated by Dru Lavigne about 3 years ago

  • Private changed from Yes to No

Also available in: Atom PDF