Project

General

Profile

Bug #24774

ActiveDirectory did not bind to the domain

Added by Alex Tunev about 3 years ago. Updated about 3 years ago.

Status:
Closed: Not Applicable
Priority:
Nice to have
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

We have an Active Directory domain with Russian-language characters in usernames and group names. The connection to the domain goes well, but the following log appears in the console:

Jun 22 15:11:24 Srvstorage /cachetool.py: [common.freenasusers:354] Directory Users could not be retrieved: 'ascii' codec can't decode byte 0xd0 in position 3: ordinal not in range(128)
Traceback (most recent call last):
  File "/usr/local/www/freenasUI/common/freenasusers.py", line 351, in __init__
    self.__users = dir(**kwargs)
  File "/usr/local/www/freenasUI/common/freenasldap.py", line 2568, in __init__
    super(FreeNAS_ActiveDirectory_Users, self).__init__(**kwargs)
  File "/usr/local/www/freenasUI/common/freenasldap.py", line 2439, in __init__
    super(FreeNAS_ActiveDirectory, self).__init__(**kwargs)
  File "/usr/local/www/freenasUI/common/freenasldap.py", line 1551, in __init__
    self.load_config()
  File "/usr/local/www/freenasUI/common/freenasldap.py", line 1645, in load_config
    val = self.configval("ad_%s" % var)
  File "/usr/local/www/freenasUI/common/freenasldap.py", line 1638, in configval
    return get_freenas_var_by_file(FREENAS_AD_CONFIG_FILE, var)
Jun 22 15:11:24 Srvstorage /cachetool.py:  File "/usr/local/www/freenasUI/common/system.py", line 96, in get_freenas_var_by_file
    val = pipe.readlines()[-1].rstrip()
  File "/usr/local/lib/python3.6/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 3: ordinal not in range(128)
Jun 22 15:11:24 Srvstorage /cachetool.py: [common.freenasusers:232] Directory Groups could not be retrieved: 'ascii' codec can't decode byte 0xd0 in position 3: ordinal not in range(128)

And the above is the same for users.


In assigning permissions, I see few users from my domain. And there are few groups.

After the reboot, the "ActiveDirectory did not bind to the domain" alert appears and the following repeating text appears in the console:

Jun 22 15:30:09 Srvstorage python: dnssd_clientstub ConnectToServer: connect()-> No of tries: 1
Jun 22 15:30:10 Srvstorage python: dnssd_clientstub ConnectToServer: connect()-> No of tries: 2
Jun 22 15:30:12 Srvstorage python: dnssd_clientstub ConnectToServer: connect()-> No of tries: 3
Jun 22 15:30:13 Srvstorage python: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mdnsd Socket:8 Err:-1 Errno:2 No such file or directory
Jun 22 15:30:13 Srvstorage python: mdns: Failed to initialise lookup, error -65563

What should I do?

Screenshot_41.png (55.9 KB) Screenshot_41.png Alex Tunev, 06/26/2017 10:59 PM
11592

Related issues

Related to FreeNAS - Bug #24971: non-ASCII shared folder name crashes generation of the smb4.conf fileClosed: Duplicate2017-07-03
Related to FreeNAS - Bug #24973: Keep LC_ALL and LANG variables when starting a serviceResolved2017-07-03
Related to FreeNAS - Bug #25358: Clarify tooltip for Domain Controller fieldDone2017-07-29
Related to FreeNAS - Bug #25264: Active Directory Recovery AttemptsClosed2017-07-22

History

#1 Updated by an odos about 3 years ago

Alex Tunev wrote:

What should I do?

It looks like some parts of the FreeNAS internals don't like non-ascii characters. I recently tried to make a share named "Møøses" (for $important_reasons), and FreeNAS choked on it as well (or perhaps the Møøse bit it).

Please upload a debug file. You can generate it by clicking System -> Advanced -> Save Debug.

Out of curiosity, is your full user list visible if you type "wbinfo -u"?

#2 Updated by John Hixson about 3 years ago

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

yes, please attach a debug.

#3 Updated by Alex Tunev about 3 years ago

  • File debug-Srvstorage-20170623113636.tgz added
  • File debug-Srvstorage-20170623112148.tgz added

When Active Directory is enabled and not rebooted, "wbinfo -u" shows all users, with normal logins, in Russian.
After the reboot, the command produces a different result:

Error looking up domain users

I saved two different dumps - the first one (debug-Srvstorage-20170623112148) with the "Active Directory" option enabled and all users visible. Another dump (debug-Srvstorage-20170623113636) was saved after the reboot, when the alert "ActiveDirectory did not bind to the domain" appears and the domain is really not connected.

#4 Updated by Vaibhav Chauhan about 3 years ago

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

#5 Updated by John Hixson about 3 years ago

I can confirm this here as well. sigh, every time I fix this, it always sneaks back in ;-) Fix coming soon.

#6 Updated by John Hixson about 3 years ago

I'm finding this behavior odd since it seems to only occur during initial run of cachetool. Afterwards, runs of cachetool pose no problems.

#7 Updated by John Hixson about 3 years ago

so this appears to be some sort of synchronization issue. I am unsure what at the moment. When joining AD, everything goes as expected, cachetool runs and has these errors. In the script that cachetool runs in, I placed a wbinfo -u/wbinfo -g/getent passwd/getent group to verify the system can resolve these names/groups and it sure can, yet cachetool errors on these first run. Afterwards, I wrote a test program to getpwnam and getgrnam these entries, and of course there is no problem resolving them. So, I am going to have to dig deeper to figure this out. In the mean time (yes, it's hacky but will work), you can "rebuild cache" or do so from CLI: /usr/local/www/freenasUI/tools/cachetool.py fill.

#8 Updated by Alex Tunev about 3 years ago

I rebuilt the cache, but nothing happened. From the CLI, by clicking on the "Rebuild Directory Service Cache" button, the message "The cache is being rebuilt." From the command line "... / cachetool.py fill" no error occurred. And still there is wbinfo -u: looking up domain users
I even reconfigured the interface in English and tried everything again. Nothing helped.

#9 Updated by Alex Tunev about 3 years ago

11592

Such settings as in the screenshot - normal?

#10 Updated by Timur Bakeyev about 3 years ago

  • Related to Bug #24971: non-ASCII shared folder name crashes generation of the smb4.conf file added

#11 Updated by Timur Bakeyev about 3 years ago

  • Related to Bug #24973: Keep LC_ALL and LANG variables when starting a service added

#12 Updated by Timur Bakeyev about 3 years ago

  • Private changed from No to Yes

#13 Updated by Timur Bakeyev about 3 years ago

We found that there are execution paths when environment variables LANG and LC_ALL that are set to en_US.UTF-8 are not propagated to the underlying [Python] scripts, which makes them choke on non-ASCII objects. The simple enforcement of the UTF8 locale https://bugs.freenas.org/projects/freenas/repository/revisions/e4f811ee025a4298f0ba5f9a08e4b4457a6bcd79/diff for the rc scripts and spawned sub-processes fixes all those issues.

You are discouraged to make those changes yourself, they are scheduled to 11.0-U2, but if you still feel adventurous the file in question is /conf/base/etc/rc.conf.local.

#14 Updated by Alex Tunev about 3 years ago

Thanks for the support!
When I click on your link - You are not authorized to visit this page.
And when will the new version be published? I have a server on my desk and I can not start it at all in the production ...

#15 Updated by Vaibhav Chauhan about 3 years ago

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

#16 Updated by Timur Bakeyev about 3 years ago

  • File changeset_re4f811ee025a4298f0ba5f9a08e4b4457a6bcd79.diff added

Unfortunately, that was rescheduled to 11.0-U3, due the upcoming CVE fix... So, I attach the patch to the ticket, in case you want to try it right now.

#17 Updated by John Hixson about 3 years ago

  • Status changed from 15 to Screened
  • Assignee changed from John Hixson to Timur Bakeyev
  • Priority changed from No priority to Important

Timur, since this is related to the locale fix you and william fixed, I'm handing this over to you.

#18 Updated by Timur Bakeyev about 3 years ago

  • Status changed from Screened to 15

Alex, can you test the given patch by any chance?

#19 Updated by Alex Tunev about 3 years ago

First I'll try to update to the latest changes, and then google, how to apply the file "diff"

#20 Updated by Timur Bakeyev about 3 years ago

Well, if you don't have experience with patching it's possibly too risky to try it on a production system.

From other side it would be nice to check that this patch fixes your issue. Is it possible to get SSH access to your machine for me?

Otherwise, if you still want to try it - save the given patch to the file and SCP it to the box to the /root, for example. Then

  • SSH to the box
  • cd /conf/base/etc
  • patch rc.conf.local /root/your_patch_file

Alternatively, you may open given file in the editor(mcedit or vi) and just insert at the end of file, before the if statement:

export LANG=en_US.UTF-8

Again, if you feel uncertain about this and that you can do it correctly - please, don't try it at work :)

#21 Updated by Timur Bakeyev about 3 years ago

Ok, done.

Now, try to reboot and see how are the things now. Is it fixed or you still experience the same bugs?

#22 Updated by Alex Tunev about 3 years ago

Ok, after restart AD is work! Thanx!!! But in the console there are still such messages

bsddb3.db.DBRunRecoveryError: (-30973, 'BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery -- BDB0060 PANIC: fatal region error detected; run recovery')
Jul 25 19:30:48 Srvstorage /cachetool.py: [common.freenasusers:217] Directory Groups could not be retrieved: (-30973, 'BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery -- BDB0060 PANIC: fatal region error detected; run recovery')

And "wbinfo -u/-g" works correctly

#23 Updated by Dru Lavigne about 3 years ago

  • Status changed from 15 to Unscreened

#24 Updated by Timur Bakeyev about 3 years ago

  • Status changed from Unscreened to 15

I'm glad it works! Do I understand correctly, that in general you got all the functionality you need regarding joining the domain? Do you see your AD users in the account tab? In general, new debug log would be nice to see :)

As for the error you quoted - it may or may not be connected with the Cyrillic names and UTF8 handling in the GUI.

Can you try from the shell/SSH session:

# bash
# env
# /usr/local/www/freenasUI/tools/cachetool.py expire
# /usr/local/www/freenasUI/tools/cachetool.py fill

And see, what would be the results, both on a screen and on a console. Would that trig this PANIC message?

If nothing notable would happen - try in the same bash shell slightly different sequence:

# bash
# env
# LANG=C /usr/local/www/freenasUI/tools/cachetool.py expire
# LANG=C /usr/local/www/freenasUI/tools/cachetool.py fill

And again, check what would be on the screen and console.

#25 Updated by Alex Tunev about 3 years ago

In the first case, nothing happened. And in the second, using "LANG = C" - the console has the following messages:

Jul 27 09:36:29 Srvstorage /cachetool.py: [common.freenasusers:335] Directory Users could not be retrieved: 'ascii' codec can't decode byte 0xd0 in position 3: ordinal not in range(128)
Traceback (most recent call last):
  File "/usr/local/www/freenasUI/common/freenasusers.py", line 332, in __init__
    self.__users = dir(**kwargs)
  File "/usr/local/www/freenasUI/common/freenasldap.py", line 2568, in __init__
    super(FreeNAS_ActiveDirectory_Users, self).__init__(**kwargs)
  File "/usr/local/www/freenasUI/common/freenasldap.py", line 2439, in __init__
    super(FreeNAS_ActiveDirectory, self).__init__(**kwargs)
  File "/usr/local/www/freenasUI/common/freenasldap.py", line 1551, in __init__
    self.load_config()
  File "/usr/local/www/freenasUI/common/freenasldap.py", line 1645, in load_config
    val = self.configval("ad_%s" % var)
  File "/usr/local/www/freenasUI/common/freenasldap.py", line 1638, in configval
    return get_freenas_var_by_file(FREENAS_AD_CONFIG_FILE, var)

Jul 27 09:36:29 Srvstorage /cachetool.py:  File "/usr/local/www/freenasUI/common/system.py", line 96, in get_freenas_var_by_file
    val = pipe.readlines()[-1].rstrip()
  File "/usr/local/lib/python3.6/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 3: ordinal not in range(128)
Jul 27 09:36:29 Srvstorage /cachetool.py: [common.freenasusers:217] Directory Groups could not be retrieved: 'ascii' codec can't decode byte 0xd0 in position 3: ordinal not in range(128)

Users and groups of AD are visible to me only through the command vbInfo. On the Users and Groups tab, you can see only the built-in ones in Linux.

#26 Updated by Dru Lavigne about 3 years ago

  • Related to Bug #25358: Clarify tooltip for Domain Controller field added

#27 Avatar?id=14398&size=24x24 Updated by Kris Moore about 3 years ago

  • Status changed from 15 to 46
  • Target version changed from 11.0-U3 to 11.1

#28 Updated by Timur Bakeyev about 3 years ago

  • Status changed from 46 to 15

Hi, Alex!

There was a similar ticket #25358 by Yuriy Lobanov, where he claimed he got this problem with BDB solved by specifying short(netbios) name in the Active Directory setup. I have doubts that there is really a correlation, but can you check in your configuration, please?

#29 Updated by Timur Bakeyev about 3 years ago

  • Priority changed from Important to Nice to have

Hi Alex!

Any updates on that subject? I'd love to make sure that we fixed that cache problem as well.

#30 Updated by Timur Bakeyev about 3 years ago

  • Status changed from 15 to Closed: Insufficient Info
  • Target version changed from 11.1 to N/A
  • Private changed from Yes to No

On the primary question this is going to be fixed in 11.0-U3, for the additional ones, it seems, the error was caused by the change of the cache file format in between the versions. Regeneration of the cache should fix the problem if any.

#31 Updated by Timur Bakeyev about 3 years ago

  • File deleted (debug-Srvstorage-20170623113636.tgz)

#32 Updated by Timur Bakeyev about 3 years ago

  • File deleted (debug-Srvstorage-20170623112148.tgz)

#33 Updated by Alex Tunev about 3 years ago

I apologize for not responding. I went on holiday. Now the problem does not arise, everything is ok. But before rebuilding the cache did not help. Since this was a test server operation, I would like to reinstall the system to the cleanest latest version. Will everything be fixed there already? Or it is necessary to again something to correct in config?

#34 Updated by Dru Lavigne about 3 years ago

If you get any errors after doing a fresh install, please attach a new debug from that system and we'll take a look.

#35 Updated by Alex Tunev about 3 years ago

  • File debug-freenas-20170816075912.tgz added
  • File debug-freenas-20170816074551.tgz added

First, Active Directory works, but I do not like the general state of the system. Appears alert: "tried 10 attempts to recover service activedirectory". And after reboot, Active Directory does not work again. Maybe this is due to the fact that there is a space in the domain's logins?

#36 Updated by Dru Lavigne about 3 years ago

  • Status changed from Closed: Insufficient Info to Unscreened
  • Private changed from No to Yes

#37 Updated by Timur Bakeyev about 3 years ago

Alex, in general I'd recommend you to wait until FN 11.0-U3 will be released, that should address both of your problems.

With the update you did you removed the hot patch I've applied to your system, that solved the UTF-8 names problem. That should be in the next release.

The AD alert I believe also was fixed recently, although I can't find exact ticket number with the fix.

New release is scheduled to the next week, so the best strategy would be to just wait a bit for it and try.

#38 Updated by Timur Bakeyev about 3 years ago

  • Status changed from Unscreened to 15

#39 Updated by Timur Bakeyev about 3 years ago

  • Related to Bug #25264: Active Directory Recovery Attempts added

#40 Updated by Alex Tunev about 3 years ago

Ok, I'll wait! Many thanks to all of you who support the project and respond to inquiries !!!

#41 Updated by Dru Lavigne about 3 years ago

Alex: did U3 resolve the issue?

#42 Updated by Alex Tunev about 3 years ago

Oh yeah! At the weekend, I installed the latest release of U3 and everything works as it should and no errors occur.
Thank you all for your work!
You can close this ticket.

#43 Updated by Dru Lavigne about 3 years ago

  • File deleted (debug-freenas-20170816074551.tgz)

#44 Updated by Dru Lavigne about 3 years ago

  • File deleted (debug-freenas-20170816075912.tgz)

#45 Updated by Dru Lavigne about 3 years ago

  • File deleted (changeset_re4f811ee025a4298f0ba5f9a08e4b4457a6bcd79.diff)

#46 Updated by Dru Lavigne about 3 years ago

  • Status changed from 15 to Closed: Not Applicable
  • Private changed from Yes to No

Closiing out then.

Also available in: Atom PDF