You can look in /var/log/middlewared.log for exact reason for failure. I recently noticed a couple of users had failures in activedirectory.change_trust_pw. I added a fix for this to go into 11.3-RELEASE. change_trust_pw is called because of some changes to simplify setup / configuration of kerberized NFS in AD environments.
Leave AD on the machine:hi anodos...
I only find lines like :
[2019/11/28 09:41:12] (DEBUG) common.freenasldap.get_SRV_records():1142 - FreeNAS_ActiveDirectory_Base.get_SRV_records: looking up SRV records for _ldap._tcp.xxxxx.yyyyyy.com
Which does not shred any light on the problem for me.
i am able to ping it thrugh ist virtual address so the IP is resolved. I am not allowed to connect to it through the explorer on the server 2016.
I shold mention that i did two things at the same time:
1. upgrade to RC1
2. change the mb to a supermicro board.
I have another FreeNas server which after upgradeto RC1 WORKS just fine?
midclt call activedirectory.leave '{"username": "your AD service account", "password": "your password"}'
. This command (if it succeeds) will clear the relevant config for your AD domain. Once you have done this, retry with the webui and check contents of "/var/log/middlewared.log". This time check the verbose logging checkbox in the webui.Leave AD on the machine:midclt call activedirectory.leave '{"username": "your AD service account", "password": "your password"}'
. This command (if it succeeds) will clear the relevant config for your AD domain. Once you have done this, retry with the webui and check contents of "/var/log/middlewared.log". This time check the verbose logging checkbox in the webui.
Not a problem. We're adding that to the UI for the actual release (a button to leave the AD domain). The gist of what I want you to do is simple: cleanly leave AD, remove kerberos realm and keytab from UI, destroy kerberos ticket, and restart from clean state with logging turned up. Then check the middlewared.log.Embarrassing... I will try that when home. Thanks and will report back for others if they have samme problem.. /O
Those log messages indicate that a testjoin failed (expected), then a proper AD join succeeded. AD should be working. Does "wbinfo -t" return correctly?
This means you probably have a permissions issue and not an AD issue. Post the ACL for each path component leading to your share.Yes it does....
But when attempting to access the FreeNAS server via Windows explorer and SMB shares the server does not allow connection:
\\OB-NAS-MAIN is not accessible. You might not have permission to use this network resource. Contact the administrator ...etc...etc..
There is nothing changed from a situation when this worked except that Motherboard of the FreeNAS server has been changed.
I am attempting to connect from the server that host the ADC.
It must be something related to authorization method but I can not find what... I have tried to adjust the ACL's but no luck..only permission denied!
Those log messages indicate that a testjoin failed (expected), then a proper AD join succeeded. AD should be working. Does "wbinfo -t" return correctly?
This means you probably have a permissions issue and not an AD issue. Post the ACL for each path component leading to your share.
How is BASIC Traverse vs BASIC Full Control? Are they individualy exclusive or must both be added (for the owner)?One other item to bear in mind is that e(x)ecute for your user is required on all path components leading to a share.
If your share is /mnt/tank/foo/bar, then you need execute on /mnt/tank, /mnt/tank/foo, and /mnt/tank/foo/bar in order to access the contents of the share.
The permissions required to traverse to a share can be added by selecting the BASIC - TRAVERSE in the ACL editor.
TRAVERSE = permission to click through a directoryHow is BASIC Traverse vs BASIC Full Control? Are they individualy exclusive or must both be added (for the owner)?
Can't find out since the ACL Permissions list is not yet available)