The answer is quite complex
There are two philosophies for a SMB server on Unix/Linux
1. reduce Windows options to a level that is Linux/Unix compatible
This is how SAMBA works. It gives a Windows user access to a Linux/Unix filesystem
2. be as Windows compatible as possible for a Unix system -
even when it breaks Unix conventions
This is what Sun/Oracle did with their CIFS server - simulate a Windows 2003 server
from outside view. The problems were, that SMB groups are not compatible to Unix groups,
Windows ntfs ACL work different than any ACL pendant on Unix, most similar are nfs4 ACL
but with a complete different handling of deny rules.
Unix filesystems use UID/GID for permissions (a simple number) while Windows use SID
that are more complex with a machine or Domain reference.
The result was
Solaris use Windows SID for the SMB server as an extended ZFS attribute ,
adds an additional SMB group management and use nfs4 ACL as they are
Windows ntfs compatible- at least for allow rules
But
Management must be done mostly from outside, example, you need Windows computer
management to request connected users or open files
Permissions must be set from Windows when you need all AD users as reference
Local napp-it permission management can manage all "known users" and adds what you
cannot do from Windows like deny rules (Unix respects ACL in order while Windows checks
first deny rules then allow rules) or set permissions independent from ACL settings.
On Windows, you can lock out admin (must touch ACL for re.access), while on Unix you
cannot lockout root. A huge advantage for administration.
Fazit
Only if users are known on Solaris, you can manage them completely locally,
otherwise do this from Windows as root or AD-user mapped to root.
This may change with the newest Illumos updates on AD management
that should be available in next OmniOS stable together with SMB 2.1
