Current situation

I have an OmniOS file server which was previously in workgroup mode and used local users/groups (created on the server itself) and local passwd passwords to authenticate users that access Windows CIFS/SMB shares. Everything works as expected, /usr/bin/ls -V shows the local user and group names in the ACLs, and permissions can also be set and modified from the Windows security tab of Explorer by the Windows users.

Planned result and steps taken

Now I want to move this server to an Active Directory domain, served by a samba4 AD DC (domain mode). To ease later addition of more servers, I want to stop using local credentials and instead leverage the central AD for users, groups and passwords. The file server was joined into a test domain without problems, then I added rudimentary mapping for the admin account:

root@omnios:/root# idmap list
add     winuser:[email protected]        unixuser:root
add     wingroup:[email protected]      unixgroup:root

After that, it was possible to log in as Administrator, give permissions to AD users and groups with the Explorer security tab and then to access the folders with those Windows user accounts. No further setup was necessary and permissions worked as expected (when opening the security tab, translation from SIDs to AD user names was visible for a very short moment).

As no local users/groups apart from system ones are present, /usr/bin/ls -V shows numerical IDs which are automatically created (except for root/Administrator, whose mapping is hardcoded in idmap).

drwx------+  3 root     root           3 Oct 17 13:45 test
    user:root:rwxpdDaARWcCos:fd----I:allow
    user:2147483651:rwxpdDaARWcCos:fd----I:allow

According to the documentation, those should be lost upon reboot, but in my simple test case they seemed to persist. (Edit: I seem to have misjudged it, after reboot of the file server the permissions persist, but they are removed and changed to nobody after rebooting the domain controller.) I am a bit leery of using that simple mode because of potential trouble later on (see third question).

Questions

I have read the documentation of the different options of naming services, but some parts are still not clear to me.

• Many of the examples are about two different sets of user accounts (Unix/Windows) that should be translated, so that a user that is entered in AD can also log in to the Solaris system, has a shell and so on. Often, different names must also be mapped/translated (e. g. [email protected] <=> jdoe). In my case on the other hand, user accounts should not be stored on Solaris hosts, no login is needed and no name translation must take place. Is it still required to create those user accounts (via script or manually) on each Solaris host in addition to AD if the ACLs should be properly named afterwards?
• The AD DC has already set automatically generated UID and GID values for each newly created user as LDAP attributes - is it possible/advisable to use those instead of usernames/groupnames? I assume this would be the IDMU version on the Solaris side, but the documentation does not mention what is needed in addition to changing the setting.
• The documentation never mentions what happens if the server is taken out of the domain, moved into another domain, brought up without a DC available, changed into workgroup mode again, or have a second server with identical configuration added. In my current setup, all local users would always stay the same, so as long as user/password combinations from the clients are correct, access would be granted to them. Assuming the setup changes to domain mode, after a loss of the domain controller all ACLs would be useless (and have to be recreated by hand), because a new domain would use new SIDs and no mapping by username could take place, is this correct? If yes, what is usually done to prevent this situation?

What I am looking for in addition to the answer to these three questions is a kind of best practices or summary to guide me on the right path. I assume it would be directory-based name mapping using either AD or LDAP (I have both and they are synced automatically), but I am not really sure. I do not want to dig myself into a hole later on (lost or unusable ACLs) or do additional work for nothing (setting up additional name information systems that would never be needed in reality). I really liked the ease of use and stability of the kernel-based CIFS sharing and would like to find a solution that continues this, just with usernames/passwords in AD/LDAP instead of the local systems.