samba - Mar 2021 - Understanding ID mapping between a campus AD and a local LDAP

We cannot stop using our local LDAP at this point. The legacy issue is real--we
have a lot of data with the current uidNumbers--but we also have users in our
local LDAP that are _not_ in the campus AD, because we have accounts from other
institutions as well (stored in different OUs, and tracked via sssd as discrete
domains). Those accounts are out-of-scope for this SMB effort, but they do
necessitate that we run our own directory server.

This still leaves me confused as to what the point of Samba idmap is, though, if
it's not meant to translate a remote identity by resolving it to a local
identity.

~jonathon

________________________________________
From: samba <samba-bounces at lists.samba.org> on behalf of Rowland penny
via samba <samba at lists.samba.org>
Sent: Tuesday, March 23, 2021 11:07 AM
To: sambalist
Subject: Re: [Samba] Understanding ID mapping between a campus AD and a local
LDAP

On 23/03/2021 16:50, Jonathon A Anderson wrote:
> I'll try to describe our situation as completely as possible:
>
> - Our campus runs active directory. It contains an entry for every campus
identity / account, as you'd expect.
>
> - Our (research computing / unixy) group runs an LDAP server (389 Directory
Server) that has the same usernames as are in the campus active directory, but
potentially different uidNumbers.
>
> - We have data in multiple shared file systems within our (research
computing / unixy) environment. We are trying to make some of this data
available via SMB.
>
> - Our Samba server is joined to our campus AD, and we are trying to map the
identities in the campus AD to the identities in our internal LDAP by matching
up usernames.
>
> - So if I log into Samba (e.g., with macOS Finder) with my AD credentials,
I want it to see my name is "username" in AD, authenticate, then look
up "username" in our internal LDAP (either via LDAP using
idmap_rfc2307, or via NSS using idmap_nss) to find what my UID number is in the
Unix environment, ignoring what AD says my UID number should be.
>
> If this is not what Samba idmap is for (or, at least, what idmap_rfc2307 or
idmap_nss is for), then I do not understand what Samba idmap is for.

Are you using the 389 Directory Server just for authentication ? Using
exactly the same users & groups that are in AD ?

If so, then probably the best way out of this is to join all your Unix
machines to your AD and use the winbind 'rid' backend on all of them,
Unfortunately you will get new Unix ID's, but I think this will happen
with whatever method you end up using. The big benefit to using AD, you
will be able to turn off the 389 Directory server and then have only one
point of management.

If you are using the 389 Directory Server for more than authentication
(mailserver for instance), then it would be a bit more difficult, but
the above should still work.

Rowland



--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

I take it you can't make or want to make the local LDAP domain a 
sub-domain of the Campus AD infrastructure?? Retired now, but years ago, 
as the firm I worked for, acquired other firms, we would often make 
their AD infrastructure a sub domain of ours, this let us qualify and 
gracefully retire user access once we removed the issues/dependencies 
encountered, but would still let parent domain new users have access to 
the legacy objects as we migrated them.? We then could retire OUs, etc. 
that where effectively unused at point of retirement.

-DD

On 03/23/2021 10:13, Jonathon A Anderson via samba
wrote:
> We cannot stop using our local LDAP at this point. The legacy issue is
real--we have a lot of data with the current uidNumbers--but we also have users
in our local LDAP that are _not_ in the campus AD, because we have accounts from
other institutions as well (stored in different OUs, and tracked via sssd as
discrete domains). Those accounts are out-of-scope for this SMB effort, but they
do necessitate that we run our own directory server.
>
> This still leaves me confused as to what the point of Samba idmap is,
though, if it's not meant to translate a remote identity by resolving it to
a local identity.
>
> ~jonathon
>
> ________________________________________
> From: samba <samba-bounces at lists.samba.org> on behalf of Rowland
penny via samba <samba at lists.samba.org>
> Sent: Tuesday, March 23, 2021 11:07 AM
> To: sambalist
> Subject: Re: [Samba] Understanding ID mapping between a campus AD and a
local LDAP
>
> On 23/03/2021 16:50, Jonathon A Anderson wrote:
>> I'll try to describe our situation as completely as possible:
>>
>> - Our campus runs active directory. It contains an entry for every
campus identity / account, as you'd expect.
>>
>> - Our (research computing / unixy) group runs an LDAP server (389
Directory Server) that has the same usernames as are in the campus active
directory, but potentially different uidNumbers.
>>
>> - We have data in multiple shared file systems within our (research
computing / unixy) environment. We are trying to make some of this data
available via SMB.
>>
>> - Our Samba server is joined to our campus AD, and we are trying to map
the identities in the campus AD to the identities in our internal LDAP by
matching up usernames.
>>
>> - So if I log into Samba (e.g., with macOS Finder) with my AD
credentials, I want it to see my name is "username" in AD,
authenticate, then look up "username" in our internal LDAP (either via
LDAP using idmap_rfc2307, or via NSS using idmap_nss) to find what my UID number
is in the Unix environment, ignoring what AD says my UID number should be.
>>
>> If this is not what Samba idmap is for (or, at least, what
idmap_rfc2307 or idmap_nss is for), then I do not understand what Samba idmap is
for.
>
> Are you using the 389 Directory Server just for authentication ? Using
> exactly the same users & groups that are in AD ?
>
> If so, then probably the best way out of this is to join all your Unix
> machines to your AD and use the winbind 'rid' backend on all of
them,
> Unfortunately you will get new Unix ID's, but I think this will happen
> with whatever method you end up using. The big benefit to using AD, you
> will be able to turn off the 389 Directory server and then have only one
> point of management.
>
> If you are using the 389 Directory Server for more than authentication
> (mailserver for instance), then it would be a bit more difficult, but
> the above should still work.
>
> Rowland
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

On 23/03/2021 17:13, Jonathon A Anderson wrote:
> We cannot stop using our local LDAP at this point. The legacy issue is
real--we have a lot of data with the current uidNumbers--but we also have users
in our local LDAP that are _not_ in the campus AD, because we have accounts from
other institutions as well (stored in different OUs, and tracked via sssd as
discrete domains). Those accounts are out-of-scope for this SMB effort, but they
do necessitate that we run our own directory server.
>
> This still leaves me confused as to what the point of Samba idmap is,
though, if it's not meant to translate a remote identity by resolving it to
a local identity.

OK, there are a few idmap backends:

idmap_ldap is an allocating backend: I do not think you could use this 
with AD.

idmap_nss maps Unix users and groups to Windows accounts: This would 
require local Unix users & groups (with the same names) in AD and 
/etc/passwd & /etc/group, so would use the local ID's. Not really 
required as the 'rid' backend will work similarly without the local 
users & groups.

idmap_rfc2307 reads id mappings from RFC2307 records in an LDAP server: 
This will use any uidNumber & gidNumber attributes in AD

idmap_ad reads all RFC2307 records in an AD server

idmap_rid calculates id mappings from SID's in an AD server

idmap_autorid works in a similar way to idmap_rid, but works with 
multiple domains

It might help if you post the smb.conf files you have tried.

Rowland