OmniOS, Napp-it, smb share and ad local domain group

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

rchristophe

New Member
Aug 29, 2016
29
0
1
Hello. I'm having a strange problem accessing an SMB share.

here is the configuration: an OmniOS CE r151030 server, napp-it, a dataset shared with smb, and a windows 10 or windows 7 client.

Both the client and the server are members of an AD domain. At AD level, there is a local group and a global group. The global group is a member of the local group. A user is a member of the global group.

When access to the dataset is set for the global group, access from the client is possible via the server's ip address or FQDN.

When access to the dataset is set for the local group, access from the client is only possible from the ip address of the server. Access is denied using the FQDN.

If I add the user as a member of the local group, access is possible from the ip address but still not from the FQDN.

It seems that nested groups only work when accessing using the ip address of the OmniOS server.

It works very well when sharing is on a Windows server.

Anyone have an idea.
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,184
113
DE
I have not seen such a behaviour (AD 2019, OmniOS AD member, Win10 Pro, simple hostname). Maybe you should ask at Illumos discuss where SMB developpers may answer, Topicbox
 

rchristophe

New Member
Aug 29, 2016
29
0
1
How do you understand the note of this solaris documentation?

Can Windows domain local groups not be used for ACLs to access directories and files?

Cannot Add Windows Local Groups to Access Control List - Managing SMB File Sharing and Windows Interoperability in Oracle Solaris 11.2

Cannot Add Windows Local Groups to Access Control List
You cannot use Windows local groups to assign security on remote systems. You can use local group only on the individual computer on which it is created. A local group is not stored in the domain SAM database.

Windows domain controllers are an exception to this behavior. Domain controllers share a set of local groups that can be shared only with other domain controllers. To make security assignments to the Oracle Solaris SMB service, use global groups.

The Oracle Solaris SMB service has its own set of local groups that are provided for Windows compatibility purposes. These local groups permit a limited set of privileges, and they can also be used for security assignments to individual files and folders.

Note - Windows domain local groups are not supported.
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,184
113
DE
How do you understand the note of this solaris documentation?
If Solaris is an AD member, you can use local Solaris smb-groups or users and AD groups and users as credidentials for shared files. You cannot use local user/groups from a Windows machine. They are only valid on this Windows machine.

If you create local Windows users and local Solaris users with same passwords, you can connect a share without entering name/password again.
 

rchristophe

New Member
Aug 29, 2016
29
0
1
It works fine now.
I took the server out of the domain, destroyed the computer object, updated OmniOs to r151032, created a new computer object and then joined the domain again.

I do not know if it was the update of OmniOs that solved my problem or to recreate a computer object in AD.:)