Learn more about these different git repos.
Other Git URLs
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
changelog: => The administrator would be able to use userPrincipalName as an expansion in the home directory templates. design: => N/A (trivial)
review: 0 => 1
owner: somebody => preichl
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1137015
rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=1137015 1137015]
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,
john@example.com
john@subdomain.example.com
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?
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]:
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.
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.
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
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3382
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.