This is a help article avoid some mistakes that we may make when configuring authentication. An error in authentication can lead to data access issues. Hence, its important to understand the command and its parameters and also take necessary precautions so that we avoid making unforced errors.

Recently we had a customer who had been working on their setup for more than a year. They had configured with AD + RFC2307. However, in their environment they had 2 Domains. Both domains had same users and groups – but different SIDs. So, a user X on one domain was not the same as the other domain as they had different SID each.

Issue they are now facing is that users from the main domain they had configured with, cannot access the data. Upon checking initial configuration, we can see that users from the domain have been assigned with AUTO range UID/GID rather than RFC2307 ranges as set during configuration of the auth command.

Now, lets analyze this issue and before that understand the customer environment.

So, as mentioned, the have 2 domains – For example: domain-scale.com and the other as domain_scale.com
Now, they have configured their cluster with domain-scale.com for RFC2307. Even though domain_scale.com have same users, due to being a distinct server, they could not use same unixmap-range and hence went for AUTO range for that.

Expected config – domain-scale.com -> RFC2307 range
and domain_scale.com -> AUTO range.

Reality – domain-scale.com -> AUTO range
and domain_scale.com -> RFC2307

As of this release we do not support overlapping Unixmap-domains ranges. Hence, each domain must have DISTINCT range set for unixmap-domains. All their Linux clients has range of RFC2307 already used by domain-scale.com and hence, they did not have any other range. Due to this, they did not mention this domain specifically when configuring auth. This means, if any user or group login from this domain, they will be assigned with AUTO range – AS EXPECTED.

So, here is how their system looked:

# mmuserauth service list
FILE access configuration : AD
PARAMETERS VALUES
————————————————-
ENABLE_NFS_KERBEROS false
SERVERS X.X.X.X
USER_NAME USERNAME
NETBIOS_NAME scale_netbios
IDMAP_ROLE master
IDMAP_RANGE 10000000-299999999
IDMAP_RANGE_SIZE 10000000
UNIXMAP_DOMAINS Domain-Scale(999-20000)
LDAPMAP_DOMAINS none
OBJECT access not configured
PARAMETERS VALUES

As you can see, the RFC2307 is configured for domain-scale. Any other domain coming in will be treated as Auto range.

Now coming back to their issue…
If they have configured with the “Correct” domain for RFC2307, then why are users from that domain being assigned AUTO range.

Now, here is the reveal
During our webex with customer, we checked for different parameters. The value that is passed to the command, “mmuserauth service create” when configuring auth with unixmap-domains, accepts NETBIOS name of the domains whom you wish to add with RFC2307 ID Mapping.

In this customer’s case, their domain names and net bios names were like so:
Domain -> domain-scale.com – NETBIOS name -> domain_scale
Domain -> domain_scale.com – NETBIOS name -> domain-scale

So, if you see they had mixed up the netbios names and domains names.

Now, due to this, when they ran “mmuserauth service create” command, when they thought they were actually passing the DOMAIN name as domain-scale , they were in actual, passing the NETBIOS Name.

# mmuserauth service create –type ad –data-access-method file –netbios-name scale_netbios –user-name xxxxxx –idmap-role master –servers X.X.X.X –password xxxxxxxxx –idmap-range-size 10000000 –idmap-range 10000000-299999999 –unixmap-domains ‘Domain-Scale(999-20000)’

Now netbios name of doman-scale is actually for domain, domain: domain_scale.com
So, instead of configuring domain-scale.com with RFC2307 as needed, they had by mistake configured domain_scale.com.

Hence, expected domain: domain-scale.com was configured as AUTO and
domain_scale.com was configured as RFC2307.

ConclusionGo through the manpage to understand the command that you will be running. Keep all the parameters ready with correct values. Making even a small error in authentication configuration, can cause severe access issues.

Join The Discussion

Your email address will not be published. Required fields are marked *