On Premise user created with proper UPN but once DirSync'd to Office 365 we notice the wrong suffix.

Though we have multiple accepted domains, when one particular UPN suffix is DirSync'd to office 365 we end up with the wrong suffix for the user's User Principal Name.  
Where could that be occurring?  If in DirSync, where?
We are having to manually modify the UPN in cloud with Powershell.

UPN on premise       --->  UPN in cloud
user@contoso.com  --->  user@domain.com
LVL 8
K BAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vasil Michev (MVP)Commented:
What kind of suffix does the user get in O365, does it match the default domain?
0
K BAuthor Commented:
No but it is an accepted domain.
0
Vasil Michev (MVP)Commented:
So it seems like some sync rule is doing this. Have you reviewed the dirsync/addsync rules, you can temporary disable any custom/modified ones to see if it makes a difference.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

K BAuthor Commented:
It turns out that the user is created on premise (by FIM) with no User Principal Name

Oddly, the UPN given in the cloud is not the default domain.
There must be some logic in dirsync to choose that?
0
Vasil Michev (MVP)Commented:
If no UPN is present, it will use the SamAccountName. But the domain part should be the default one, that's why I asked you above. My bet is some rule in FIM is making this happen.
0
K BAuthor Commented:
FIM is making it blank yes.  It is supposed populate it later in the day (full day to on board) on premise.
Makes sense that SamAccountName is the prefix used for UPN
the rule in DirSync looks like this for UPN sync:

cd.user_inetOrgUser:dn,sAMAccountName,userPrincipalName->mv.person:userPrincipalName

If I create a test user (leaving FIM out of the picture) with a blank UPN the same thing happens.. so I would think I would lean toward DirSync.. Thoughts?
0
Vasil Michev (MVP)Commented:
Oh, I thought you use FIM for the sync as well. Anyways, seems I can repro this on one test tenant. When the user doesnt have UPN populated, the domain part does NOT correspond to the default MSOL domain (Get-MsolDomain | ? {$_.IsDefault -eq $true}), but seems to automatically pick the federated domain.

I'll test with non-federated domain later, if I manage to find a test tenant :)
0
K BAuthor Commented:
there are 5 federated domains in this case and this one is not the default either.
has me stumped.
0
K BAuthor Commented:
Vasil,

In your case what is the 'DC=Domain'?
0
Vasil Michev (MVP)Commented:
Good hunch, it does populate the on-prem domain. Here's the actual mapping:

Source                : {sAMAccountName, userPrincipalName}
Destination           : userPrincipalName
FlowType              : Expression
ExecuteOnce           : False
Expression            : IIF(IsPresent([userPrincipalName]),[userPrincipalName],
                        IIF(IsPresent([sAMAccountName]),([sAMAccountName]&"@"&%Domain.FQDN%),Error("AccountName is not present")))

Open in new window

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
K BAuthor Commented:
wow where do you find that mapping?!
0
K BAuthor Commented:
I can ask a new question on that. it is out of scope.
:-)
0
RHCommented:
If UPN is not assigned, synched user would have UPN suffix from Distinguished name (DN).

In Active Directory, the default UPN suffix is the DNS name of the domain in which user account created.

https://technet.microsoft.com/en-us/library/cc739093(v=ws.10).aspx
0
Vasil Michev (MVP)Commented:
That's on the 'In from AD - User AccountEnabled' rule (using AADSync on that this machine). No need for new question, you got the answer yourself :)
0
K BAuthor Commented:
Yeah but my DirSync does not show this detail (is it because you have the new AADSync?)
Source                : {sAMAccountName, userPrincipalName}
Destination           : userPrincipalName
FlowType              : Expression
ExecuteOnce           : False
Expression            : IIF(IsPresent([userPrincipalName]),[userPrincipalName],
                        IIF(IsPresent([sAMAccountName]),([sAMAccountName]&"@"&%Domain.FQDN%),Error("AccountName is not present")))

Where does it show it here? or is this not the correct place to look?
2015-06-11-1154.png
0
Vasil Michev (MVP)Commented:
This is the mapping when you are using Dirsync. Now, editing the rule extention is a different matter, and I have no idea how to do it :)

You can simply map another attribute to use as UPN, but that will affect every object, so be very very careful with that. Or you can just replace it with direct mapping UPN->UPN, so that objects without UPN will not sync. But better yet, ask the gurus at the FIM forums on TechNet: https://social.technet.microsoft.com/Forums/en-US/home?forum=ilm2
0
K BAuthor Commented:
I just want to see where that default mapping is in DirSync - i dont want to change it.
I don't see the below like you..

Source                : {sAMAccountName, userPrincipalName}
Destination           : userPrincipalName
FlowType              : Expression
ExecuteOnce           : False
Expression            : IIF(IsPresent([userPrincipalName]),[userPrincipalName],
                        IIF(IsPresent([sAMAccountName]),([sAMAccountName]&"@"&%Domain.FQDN%),Error("AccountName is not present")))
0
Vasil Michev (MVP)Commented:
What you see there is just the rule 'name', the actual function is not exposed. But yes, this is the mapping that explains this behavior.
0
K BAuthor Commented:
so how did you expose it?  can you tell i really want to see that lol
0
Vasil Michev (MVP)Commented:
I didn't, the one I pasted is from AADSync. I'm just assuming that it does the same thing, as we have actually confirmed with our tests. Afaik, those functions are 'hidden' inside some DLL for the dirsync client, but if you want a definitive answer, post this on the TechNet FIM forums where the gurus are :)

The behavior makes sense, although I've always assumed that this is done on the service side. Now I know its client side, and that we have control over it.
0
Vasil Michev (MVP)Commented:
There's some veeeeery old documentation here: https://technet.microsoft.com/en-us/library/cc720667(v=ws.10).aspx
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Office 365

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.