OmniOS with Napp-It, AD integration problems

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

snerran

New Member
Oct 31, 2013
13
0
1
Stockholm, Sweden
Hi all!

I've been trying to get SmartOS with Napp-It to work with my Active Directory domain. Joining wasn't a problem. It is the sharing of folders that is driving me crazy. I've been trying to set this up for weeks now. Any help / insight would be greatly appreciated.

This is what my network contains:

  • ESXi 5.5 hosting all my virtual servers.
  • AD Domain with domain and forest function level of "Windows Server 2012 R2".
  • 2 x Domain Controllers running Windows Server 2012 R2
  • 1 x File server running Windows Server 2012 R2
  • 1 x Plex Media Server running Windows Server 2012 R2
  • 1 x Test server running Windows Server 2012 R2
  • 1 x NAS/SAN running OmniOS with Napp-It
  • 1 x Physical workstation running Windows 8

Initially I was using my Windows Server as a file server. The performance on it is terrible and I've been reading up on ZFS and really want to use it's benefits. Prior to deploying my SAN/NAS VM i was reading on several websites that AD integration is no problem with Solaris-based operating systems. It took me some days of reading when I finally decided to go with OmniOS and Napp-It.

For testing purposes I am using Gea's Napp-In-One solution (v14a): napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris downloads

Like I said, joining my AD domain was no problem. I've created a ZFS pool and created a folder called "public" with guest access enabled. All permissions are set to default. Meaning I have not set any permissions. The permissions that are set are the ones that were created when the shared folder was created by me. Same thing goes for the share ACLs.

Actually the only thing a did was add some user mappings:

Your current mappings: idmap list

Code:
add 	winuser:oden@domain.local	unixuser:root
add 	wingroup:administrators@domain.local	unixgroup:root
add -d	"wingroup:domain [email]admins@domain.local[/email]"	unixgroup:root
add -d	"wingroup:SG-Domain [email]Administrators@domain.local[/email]"	unixgroup:root
add -d	winuser:snerran@domain.local	unixuser:root
add 	winuser:*@domain.local	unixuser:*
add 	"wingroup:Domain [email]Users@domain.local[/email]"	unixgroup:users
add 	"wingroup:Domain [email]Admis@domain.local[/email]"	unixgroup:staff
If I try to access the NAS/SAN server (Start > Run > \\napp-iy-14a) from my physical workstation that is NOT domain joined I can access the shares without a logon prompt. I can even edit file and folder permissions.
If I try to access the NAS/SAN server (Start > Run > \\napp-iy-14a) from any of my domain joined Windows servers I get a logon prompt. Trying to authenticate with any of my AD accounts do not work, it only results in a locked out account. If I do however authenticate with the root user and password on the SAN/NAS VM I can access it but then receive the following error message:

"\\napp-it-14a is not accessible. You might not have permissions to use this network resource. Contact sysadmin.... The remote procedure call failed and did not execute"

After some searching I found this guide: http://info.nexenta.com/rs/nexenta/images/doc_3.0_win7cifs.pdf

OK, so it might be GPO related. So I moved my test server running Windows Server 2012 R2 to an OU that has no GPOs applied to (blocked inheritance). I then once again tried to access the NAS/SAN server. Please note that the Windows Server 2012 R2 machine is still domain joined. This thime I also received a logon prompt and no domain account works, only root. But if I authenticate with the root user I do not receive the error message above, I can see the shares on the server and edit permissions. So my question/problem, how do I get rid of the logon prompt? If both the Windows Server and OmniOS servers are joined in the domain and user mappings have been setup, no authentication should be required, no?
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
What is the reason for your mappings as you do not need any mappings for SMB -
the only mapping I do usually is a mapping like domainadmin => user root to have full access as domainadmin.
Otherwise you need to login as root via SMB to manage permissions.

I would start without a mapping (beside the basic above) and ACL settings that allow modify for everyone@
 

snerran

New Member
Oct 31, 2013
13
0
1
Stockholm, Sweden
Thank you for your reply :)

To be honest there is no real reason. It is just left overs from me trying to troubleshoot the problem. This is how my user mapping looks now:

Code:
Your current mappings: idmap list

add winuser:oden@domain.local unixuser:root
Please note that my default domain admin account is renamed to "oden".

ACL settings are as follow:

ACL on folders:


https://drive.google.com/file/d/0BzEaXm348GjsREl0Qjh0emJsUzA/edit?usp=sharing

ACL on SMB shares:


https://drive.google.com/file/d/0BzEaXm348GjsWkswYjJFMmoweGs/edit?usp=sharing

I also restarted SMB server after making the above changes:

Code:
svcadm restart smb/server
Still I get the "Enter network credentials" logon prompt from my Windows Server 2012 R2 VMs, but not from my physical workstation that is not domain joined. You reckon it might be GPO related? Because it works from my non-domain joined Windows 8 workstation.
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
When did you start your domain controller.
Before or after OmniOS?

On an napp-in-one config, you need a second napp-in-one or must place your ad controller on your local datastore and start it prior OmniOS or OmniOS cannot join the domain correctly on a reboot.

You can do a rejoin to check. If you connect from a non-domain workstation with valid local credentials or a stored last login, you can connect without a login.
 

snerran

New Member
Oct 31, 2013
13
0
1
Stockholm, Sweden
Both DC and OmniOS are on a local datastore. Both DCs are startet before OmniOS VM.

I don't really understand what you mean with?

If you connect from a non-domain workstation with valid local credentials or a stored last login, you can connect without a login.
Are you suggesting I do a re-join to the domain of the OmniOS VM? Meaning, delete the OmniOS computer object in the domain AD and then do a re-join?

EDIT:
I've now dis-joined OmniOS from my domain. I joined a workgroup, deleted the computer object in the AD and removed the DNS-record. I also removed all user mappings. Now I can't join the domain....

Code:
Joining domain.local ... this may take a minute ...
failed to join asgard.local: UNSUCCESSFUL
Please refer to the system log for more information.
Tried doing it via shell as well, result is the same though... :-( Another interesting observation is that even if it fails joining my domain, it creates the computer object for OmniOS in my AD (?).

Just for kicks I tried accessing OmniOS from one of my domain joined Windows Server 2012 R2 VMs while OmniOS was member of a workgroup. This time I did not receive a logon prompt. So the problem is definitely related to it being joined to a domain. The problem now is that I cannot re-join my domain. Any ideas what got broken?
 
Last edited:

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
Quite often I need two or three efforts until I get a successful. Only thing you can try is to delete the computer account from your domain and retry.

I also have had an always unsuccessful in some rare cases where I was not able to join. I could fix it either with a reboot to a former BE or a reinstall of OmniOS (Not sure what has happened but a reinstall/ boot another BE was much faster than endless searching)
 

snerran

New Member
Oct 31, 2013
13
0
1
Stockholm, Sweden
Thank you for the suggestions.

I've re-deployed a new OmniOS with Napp-It VM. Joining my domain was unsuccessful. I tried many times and deleted the computer object between the retries. I then by accident only supplied the IP of my second domain controller, then my OmniOS VM was able to join the domain. I have no idea why it do not want to join the domain when supplying my first DC in the domain. Anyway, the new OmniOS VM is now member of the domain and once again I receive the "supply network credentials" prompt when trying to access the server from any of my domain joined Windows VMs. The only user mapping set is
Code:
"winuser:oden@domain.local	unixuser:root"
. ACL permissions are as they should be. Basically I'm on square 1 one again. Anyone else having these problems?

How many DCs do you have in your domain? Is it Server 2012 or 2008 R2 domain? Have you aplied any special GPOs on your domain?
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
We have a domain with two routed networks each with 2 domain controller. Until last summer we used 2008r2 now we are on 2012.

I can remember of a similar problem (login prompt) only in a timeframe after we modified one of the ad servers. I suppose it was the timeframe they needed to get in sync. In that case a restart of OmniOS or the smb service after a few minutes fixed the problem.

Do you have the same problem if only the master ad controller is online.
 

snerran

New Member
Oct 31, 2013
13
0
1
Stockholm, Sweden
Good idea. I've shut down the first DC (dc1.domain.local). Unfortunately the exact same problem still exists.

If I go to Napp-It Web GUI > Services > SMB > Active Directory, I see the following at the top of the page:

Code:
Current state of SMB/CIFS Server: online 
Current membership: domain [DOMAIN] [*] [domain.local] [+dc2.domain.local] [192.168.1.11] [.] [OMNIOS] [S-1-5-21-707882941-470019427-3866407743] [*] [DOMAIN] [S-1-5-21-1214965037-2911195281-443400084]
Dunno if that is correct or not. I guess it is as I was only able to re-join the domain if I supplied the IP of the second DC (dc2.domain.local). Any more tricks up your sleeve? :)
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
Good idea. I've shut down the first DC (dc1.domain.local). Unfortunately the exact same problem still exists.

If I go to Napp-It Web GUI > Services > SMB > Active Directory, I see the following at the top of the page:

Code:
Current state of SMB/CIFS Server: online 
Current membership: domain [DOMAIN] [*] [domain.local] [+dc2.domain.local] [192.168.1.11] [.] [OMNIOS] [S-1-5-21-707882941-470019427-3866407743] [*] [DOMAIN] [S-1-5-21-1214965037-2911195281-443400084]
Dunno if that is correct or not. I guess it is as I was only able to re-join the domain if I supplied the IP of the second DC (dc2.domain.local). Any more tricks up your sleeve? :)
Is the dc2 your primary ad controller or your backup controller?
(Primary must stay online)
 

artbird309

New Member
Feb 19, 2013
25
2
3
Good idea. I've shut down the first DC (dc1.domain.local). Unfortunately the exact same problem still exists.

If I go to Napp-It Web GUI > Services > SMB > Active Directory, I see the following at the top of the page:

Code:
Current state of SMB/CIFS Server: online 
Current membership: domain [DOMAIN] [*] [domain.local] [+dc2.domain.local] [192.168.1.11] [.] [OMNIOS] [S-1-5-21-707882941-470019427-3866407743] [*] [DOMAIN] [S-1-5-21-1214965037-2911195281-443400084]
Dunno if that is correct or not. I guess it is as I was only able to re-join the domain if I supplied the IP of the second DC (dc2.domain.local). Any more tricks up your sleeve? :)
That does look correct, when I am having problems with my OI server not letting my AD users sign in I don't see the SID in the menu [S-1-5-21-707882941-470019427-3866407743] that is the domain computer account.

I was having problems similar to this but it depended on what computer I was using. I created a GPO like the PDF you liked and took me a while to get them set right for all my Windows computers to connect without problems.

Here is how my GPO is set to help my Windows computers connect to my OI server.


I hope this helps.
ARTbird309
 

snerran

New Member
Oct 31, 2013
13
0
1
Stockholm, Sweden
artbird309: Thank you very much for the tip. I terminated the old OmniOS VM and re-deployed a new one. I then did a reset of my Default Domain Controller Policy. Meaning the GPO is set to the defaults when you create the first DC in a new forest with a new domain. I then shut down my second DC (dc2.domain.local). After that I joined the new OmniOS VM to the domain. Finally that worked like a charm. To my great surprise I was then able to access the OmniOS VM from my first DC (Start > \\omnios) without having to supply credentials. When I did the same thing from another domain joined Windows 2012 R2 server, the dreaded logon prompt appeared. So now I was having the same problem as you had, meaning it all depends from which machine I try to access OmniOS VM. I created a GPO as you suggested, linked it to a Test OU with my test Windows 2012 R2 Server in it. Note that the Test OU has blocked inheritance, so only the new GPO is applied. Still no luck though :(

How did you find out about the above GPO settings would work? Maybe I need to enable/disable some other GPO setting.

EDIT:
I've done some extensive searching on the problem above. As of now I've ended up with the following GPO setting on the test Windows Server VM:

https://drive.google.com/file/d/0BzEaXm348GjsWXpmZWIwZU1Rc2M/edit?usp=sharing

Unfortunately that doesn't seem to help either. Still only works accessing OmniOS VM from my DC. I also tried setting the following but without luck:

Code:
root@omnios:/# sharectl set -p lmauth_level=2 smb
 
Last edited:

snerran

New Member
Oct 31, 2013
13
0
1
Stockholm, Sweden
After several hours of troubleshooting, Google searching, GPO editing and re-deploying of OmniOS VMs I figured I would test if Solaris had the same problem in my domain. So I downloaded Oracle Solaris 11.1 installed it and joined it to my domain. BOOM! It worked, no hiccups and no dreaded logon prompts. I even reverted back to my old GPOs that are based on Microsoft's security compliance GPO baselines. Meaning none of my GPOs have disabled digitally signed communications for client or server, and still it works like a charm with Solaris.

Why I had so much problems with OmniOS I do not know. It is a shame, because I rather use OmniOS for my SAN/NAS solution. Still I need something that works and do not have inconsistent and unpredictable behavior, which I experienced with OmniOS. It would be really interesting to hear if others had these problems with AD integrated OmniOS + Napp-It. Actually I would leave Napp-It out of it. I believe the culprit here is OmniOS.

Speaking of Napp-It. Thank you so much gea for your help and an awesome solution/product. Napp-It is a really easy and time saving tool. Although I wish the actual GUI would be more eye pleasing and easier to navigate through.

Now I have to pass-through my M1015 to my Solaris VM and setup my ZFS pool.