Accessing SAMBA share with AD account from a trusted domain

Question

My company is planning a migration of users, computers, and groups from an acquired company. Both companies have Active Directory domains and there is a 2 way trust between them. The other company has data on linux servers that are accessed via SAMBA and secured using their AD users and groups. We are hoping to do a staged migration of a subset of objects over a period of time rather than migrate all objects at once.

The question is, after a user is migrated to our domain will they still be able to access the SAMBA share in the trusting domain?

Answer 1

This depends on how those Samba servers are configured to handle the Username/UID and Groupname/GID mapping. This is done with the idmap directives. There are a couple of ways to configure Samba to handle this, but which one is in use will impact how they're able to handle cross-domain trusts and accounts migrating between domains.

The manual for this is here:

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html

If they're using the default Winbind back-end, a database that matches Domain\Username pairs to local UIDs, when accounts migrate across domain boundaries they'll appear as new users to Samba. This is because their SID changes as they cross the domain boundary. However, this model does allow cross-domain usage over a trust.

If they're using the the RID back-end, the Samba server will NOT be able to allow access to users in different domains. If this is the case, you're probably already aware of it. When users move out of the domain the Samba server exists in, they will lose all access to it.

If they're using an LDAP server as a way to share Username/UID mappings across multiple Samba servers, the same restrictions as the default back-end apply. However, each Samba server will have the same Username/UID mapping. The upside is that you might be able to directly edit the LDAP server after migration to a new domain to ensure that the same Username/UID mapping is preserved.

The last option is perhaps your best bet for maintaining compatibility during your staged migration. However, if they're not already using an LDAP server as a central repository it will get much trickier.