#2340 [RFE] User Principal Name as a template expansion for homedir mappings
Closed: Fixed None Opened 4 years ago by viniciusferrao.

When using Enterprise Principal Names there's some situations where additional home directory mappings became important.

As example if we have two different UPNs in the same domain under the same username we have a conflict in the actual default mapping of home directories.

So a new variable with the relative domain should be enabled to map home directories, as example:

john@example.com -> /home/example.com/john [pattern: /home/%principalName/%username
john@sales.example.com -> /home/sales.example.com/john


Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.12.1
rhbz: => todo

Fields changed

changelog: => The administrator would be able to use userPrincipalName as an expansion in the home directory templates.
design: => N/A (trivial)

Fields changed

review: 0 => 1

Fields changed

owner: somebody => preichl

Mass-moving all tickets that didn't make 1.12.1 into 1.12.2

milestone: SSSD 1.12.1 => SSSD 1.12.2

Hello viniciusferrao,

could you possibly elaborate a bit more about the description of this ticket?

It look like there should be two different home directories depending which UPN is used at the login prompt. IMO this does not make sense because the underlying user is the same hence both home-directories belong to the same user.

Thanks!

Hello preichl,

Not necessary true.

As example, we can have someone named John Whatever with the following UPN:

john (@) example.com

And in the same domain we can have John Whatsover with the UPN:

john (@) subdomain.example.com

Both with valid email addresses and UPNs. In this case, the UPN is treated like as an Enterprise Principal Name (EPN). So when mapping homedirs, in the AD backend, the sAMAcccountName is used, which is not really good, so the ticket is to solve this question parsing the address and mapping the home directories accordingly.

So we can have something like this:

/home/example.com/john

/home/subdomain.example.com/john

Paid solutions, like Centrify DC does that seamlessly.

_comment0: Hello preichl,

Not necessary true.

As example, we can have someone named John Whatever with the following UPN:

john@example.com

And in the same domain we can have John Whatsover with the UPN:

john@subdomain.example.com

Both with valid email addresses and UPNs. In this case, the UPN is treated like as an Enterprise Principal Name (EPN). So when mapping homedirs, in the AD backend, the sAMAcccountName is used, which is not really good, so the ticket is to solve this question parsing the address and mapping the home directories accordingly.

So we can have something like this:

/home/example.com/john

/home/subdomain.example.com/john

Paid solutions, like Centrify DC does that seamlessly. => 1411492696918834

Replying to [comment:8 viniciusferrao]:

Hello preichl,

Not necessary true.

As example, we can have someone named John Whatever with the following UPN:

john (@) example.com

And in the same domain we can have John Whatsover with the UPN:

john (@) subdomain.example.com

Both with valid email addresses and UPNs. In this case, the UPN is treated like as an Enterprise Principal Name (EPN). So when mapping homedirs, in the AD backend, the sAMAcccountName is used, which is not really good, so the ticket is to solve this question parsing the address and mapping the home directories accordingly.

So we can have something like this:

/home/example.com/john

/home/subdomain.example.com/john

Thank you for your reply!

One solution we were considering was to use the UPN as a whole as template expansion. Would that work for you?

Paid solutions, like Centrify DC does that seamlessly.

I see. Do you have some links to Centrify documentation?

Thanks again for getting back to us.

Jakub I thought we already create home dirs with the following pattern for trusted realms:
/home/$DOMAIN/$USER so in the example above we should not really hit any issues as the 2 users come from 2 different AD domains ...

Replying to [comment:10 simo]:

Jakub I thought we already create home dirs with the following pattern for trusted realms:
/home/$DOMAIN/$USER so in the example above we should not really hit any issues as the 2 users come from 2 different AD domains ...

We do, but with enterprise principals you can have different realm portions in a single domain. Normally, when you kinit, the realm comes back canonicalized. The feature is also sometimes called Principal Name Suffixes. I assume that's what the reporter talks about, but I could be wrong. See http://technet.microsoft.com/en-us/library/cc756018%28v=ws.10%29.aspx

viniciusferrao, can you confirm the different UPNs are inside of a single realm?

Yes, It's different UPN's in a single REALM.

If the 2 users are in the same REALM (ie same AD Domain) then they will have 2 different !SamAccountNames so again no clashes.

FWIW a UPN suffix is not a realm but a DNS domain. The REALM always corresponds to the AD Domain Name uppercased in AD.

Simo.

_comment0: If the 2 users are in the same REALM (ie same AD Domain) then they will have 2 different SamAccountNames so again no clashes.

FWIW a UPN suffix is not a realm but a DNS domain. The REALM always corresponds to the AD Domain Name uppercased in AD.

Simo. => 1411508912730649

Yes, they have different sAMAccontName but the main ideia here is to make things nice to the user. If the sAMAccountName is a random number for example, the home directories will be this random number, which is not fine. So the idea here is to work on those issues.

viniciusferrao, could you please answer Jakub's question?

"One solution we were considering was to use the UPN as a whole as template expansion. Would that work for you?"

I tried to find in centrify docs any description of templates they provide to expand homedir, but I was not able to find anything regarding UPN. Could you provide me a link if you happen to have one?

Thanks.

mark: => 0

Hello preichl, here in this topic Fel, says that Centrify Standard can use any AD attribute to map homedirectories: http://community.centrify.com/t5/DirectControl-Express-for-UNIX/Override-Home-Directory-mapping-with-Centrify-Express/td-p/16788

I don't have the exactly documentation here since I'm not a paying customer from Centrify.

Fields changed

patch: 0 => 1

We need to do a release as requested by downstream. Moving tickets that are not fixed already or very close to acking to 1.12.3

milestone: SSSD 1.12.2 => SSSD 1.12.3

milestone: SSSD 1.12.3 => SSSD 1.12.2
resolution: => fixed
status: new => closed

Metadata Update from @viniciusferrao:
- Issue assigned to preichl
- Issue set to the milestone: SSSD 1.12.2

2 years ago

Login to comment on this ticket.

Metadata