SMB share broken by implementing Active Directory Domain Controller

[averyfreeman]

It isn't a prerequisite or necessary. I've configured multiple FreeNAS servers as AD domain members. Your procedure isn't required.

OK So at this point I am starting to understand this much better. I have scrapped the part of the thread that explained how I had given SeDiskOperatorPrivilege to AD user/group through username mapping because, thanks to you and all this experimentation, I realize that is a bad idea and not necessary, and I don't want someone else to repeat the same mistake.

The only thing left that is confusing me at this point is why I can only access the share from \\freenas.local instead of \\freenas or \\freenas.domain.com. I have avahi turned off, and both \\freenas and FQDN used to work when I had username mapping set up.

 

[anodos]

OK So at this point I am starting to understand this much better. I have scrapped the part of the thread that explained how I had given SeDiskOperatorPrivilege to AD user/group through username mapping because, thanks to you and all this experimentation, I realize that is a bad idea and not necessary, and I don't want someone else to repeat the same mistake.

The only thing left that is confusing me at this point is why I can only access the share from \\freenas.local instead of \\freenas or \\freenas.domain.com. I have avahi turned off, and both \\freenas and FQDN used to work when I had username mapping set up.

Sounds like a DNS problem on your client.

• Verify that your client computer is configured to use your AD Domain Controller for DNS.
• Log into your Domain Controller and verify that it can ping the FreeNAS server by FQDN.
• Run testparm on your FreeNAS server and verify that your workgroup and realm are correct.
• Run hostname on your FreeNAS server and verify that your hostname is your FQDN.
• Run host <ip of freenas server. from the FreeNAS server to double-check that DNS is resolving properly

If your Client computer had DNS configured incorrectly, you may need to resolve the DNS resolver cache on your client. On a windows client you can do this by opening powershell and typing ipconfig /FLUSHDNS

 

[anodos]

The rough procedure I use for joining a FreeNAS server to a simple domain (single domain single forest) as a "member server" (i.e. not a domain controller) is as follows:
1) Configure static IP address on FreeNAS server
2) Set AD DC as DNS server for FreeNAS server
3) Set host name of FreeNAS server to FQDN it will have on network. foo.bar.com
4) Point AD DC and FreeNAS servers to same time source
5) Configure AD with sufficient privileges for domain join.
6) Navigate to "Directory Services" -> "Active Directory" and fill out following:
a)Domain Name (bar.com)
b)Domain Account Name (account name from [5])
c)Domain Account Password

Errata:
Leave the following items checked:

• Verbose Logging
• Allow DNS updates
• Enable

Use "rid" as the idmap backend unless you have configured RFC2307 schema extensions on your AD DC.

 

[averyfreeman]

Sounds like a DNS problem on your client.

• Verify that your client computer is configured to use your AD Domain Controller for DNS.
• Log into your Domain Controller and verify that it can ping the FreeNAS server by FQDN.
• Run testparm on your FreeNAS server and verify that your workgroup and realm are correct.
• Run hostname on your FreeNAS server and verify that your hostname is your FQDN.
• Run host <ip of freenas server. from the FreeNAS server to double-check that DNS is resolving properly

If your Client computer had DNS configured incorrectly, you may need to resolve the DNS resolver cache on your client. On a windows client you can do this by opening powershell and typing ipconfig /FLUSHDNS

OK, this is interesting. So my first thing I want to mention is another client I have can connect to \\freenas just fine, and for some reason the first client I had which had a problem connecting with \\freenas connects to it fine now, too. I haven't changed anything on either the client or the FreeNAS server.

So somehow the issue resolved itself.

I ran through the steps you laid out and here are the results:

Client is set to use AD computer as only DNS and is set using IP address, not FQDN.

Logged into DC and can ping FreeNAS using FQDN just fine.

Testparm sees no issues.

Hostname on FreeNAS is FQDN.

Host <FreeNAS server's IP> results in this:

Code:

Host <FreeNAS_backwards_IP_address>.in-addr.arpa not found: 3(NXDOMAIN) 

I looked into the AD machine's DNS and I noticed there's a couple of devices on my network that don't have entries in the reverse lookup zone. Obviously the FreeNAS server is one of those that didn't get a PTR. When I set up the reverse lookup zone, it automatically created PTR entries for most of the devices, so I'm not sure why that didn't work for the FreeNAS server, which has a static IP.

At least you helped me get close to the issues, so now lots of reading about DNS and PTR / reverse lookup zones. Thanks.

 

[averyfreeman]

The rough procedure I use for joining a FreeNAS server to a simple domain (single domain single forest) as a "member server" (i.e. not a domain controller) is as follows:
1) Configure static IP address on FreeNAS server
2) Set AD DC as DNS server for FreeNAS server
3) Set host name of FreeNAS server to FQDN it will have on network. foo.bar.com
4) Point AD DC and FreeNAS servers to same time source
5) Configure AD with sufficient privileges for domain join.
6) Navigate to "Directory Services" -> "Active Directory" and fill out following:
a)Domain Name (bar.com)
b)Domain Account Name (account name from [5])
c)Domain Account Password

Errata:
Leave the following items checked:

• Verbose Logging
• Allow DNS updates
• Enable

Use "rid" as the idmap backend unless you have configured RFC2307 schema extensions on your AD DC.

Oh OK, good to know - that's definitely a different order than most of the guides I read.

Now that I've gotten this far, I have a feeling it may have had more to do with my client's DNS cache and the lack of a PTR entry in the reverse lookup zone. So not FreeNAS' fault!

 

[anodos]

Oh OK, good to know - that's definitely a different order than most of the guides I read.

Now that I've gotten this far, I have a feeling it may have had more to do with my client's DNS cache and the lack of a PTR entry in the reverse lookup zone. So not FreeNAS' fault!

Yeah, improperly configured reverse lookup zone (or lack thereof) is actually a fairly common mistake. ;)

 

[averyfreeman]

I have a big-picture question to ask:

I know by joining the FreeNAS server to the domain it can be used for user access / credentials for domain users, but is there anything else it is useful for?

Thanks,
Avery

PS: I'm trying to read up on why the PTR wasn't made automatically like the other devices, but does this just mean I need to put the PTR for FreeNAS in manually, or is in indicative of bigger problem?

EDIT: I noticed in my DNS settings for the DC the "Update associated pointer (PTR) record" was unchecked for FreeNAS. I checked it and the PTR is in the Reverse Lookup Zone now, and

Code:

host <ip of FreeNAS server>

Gets the appropriate <reverse of FreeNAS ip>.in-addr.arpa domain pointer freenas.domain.com now.

Is there anything else you think might be a problem? All 4 of the things you said I should check are now responding appropriately.