Office 365/Azure AD Sync - changing which attributes are copied (specifically 'mail')

[Garacesh]

We've been using Spiceworks helpdesk for a long time and we've come across an issue where it's not emailing users. After some digging it turns out it hasn't been doing this for a long while, and the culprit is because of the E-Mail (mail) attribute on each users' AD account. Current their mail attribute is set to their Office365 tenant email address because if the mail attribute doesn't match an Office 365 tenant name, it changes the users' Primary E-Mail Address to their [email protected] variant which just confuses and annoys everyone, but if you set their 'mail' attribute to your O365 tenant, it sets their Primary E-Mail Address properly. So that's what we've had to do.

 

However, this is resulting in Spiceworks not being able to email users when a ticket is responded to or closed, and Spiceworks doesn't have anywhere to change what attribute it uses for user emails. So I'm left with a decision to make. Somehow I'm going to have to put another entry into each users' AD account with another email address and point Microsoft's Azure AD Connect tool at that. I'm thinking of using the Web Page (wWWHomePage) attribute, since it's on the first tab of a user properties and because we already use the Office (physicalDeliveryOfficeName) attribute for G Suite.

 

Using the Synchronization Rules Editor I have found Outbound User rules (Out to AAD - User Identity; Out to AAD - User Intune; Out to AAD - User LyncOnline; Out to AAD - User SharePointOnline; Out to AAD - User AzureRMS) which list the 'mail' attribute under their Transformations section, so in theory this looks to me like I would just need to edit it from the 'mail' attribute to the 'wWWHomePage' attribute. I just wondered if anybody else had attempted this and can confirm this is right (or slap me and tell me not to touch things if I'm wrong)

Edited January 23, 2018 by Garacesh

[Steve21]

I don't really get why you aren't using the normal email one. If you have their mail set as [email protected] etc, why can't you let spiceworks email that?

 

Steve

[Garacesh]

Because that's not how the Office 365 tenant (their current mail attribute) works.

 

We have three email systems at the moment. (Personally, I hope we ditch 365 in the future, but it depends on what the staff are using and that's a discussion for another time..)

 

SchoolDomain.uk - our internal/external email. Used by staff only, it's our original email system can be used to communicate outside the domain.

SchoolDomain.net - Office 365 tenant, internal service only, used by staff and pupils.

SchoolDomain.org - G Suite for Education domain. Internal service only, used by staff and pupils.

 

The problem is there's only one 'mail' attribute per user and everyone wants to use it.

 

Google is smart enough to convert domain names, so if it sees the wrong domain in the mail attribute it simply changes it to SchoolDomain.org. Easy peasy. But SalamanderSoft needs to see their G Suite email as-is, so we opted to use the Office (physicalDeliveryOfficeName) attribute to hold that information.

 

Microsoft is a pain in the ass. If it sees a domain that isn't its own tenant, it makes the primary email address the default school.onmicrosoft.com domain rather than using the SchoolDomain.net address. It still recognises they have a SchoolDomain.net address, and it does assign them that address, but it doesn't set it as their primary email.

 

Both of these services are, as mentioned, internal services only. Spiceworks operates out of a SchoolDomain.uk email address, so it cannot email these addresses.

 

However, you can't tell Spiceworks what attribute to use for user emails, the only LDAP attribute you can change is SAMAccountName. It uses 'mail' for emails. That's it. End of discussion. So right now, it turns out, Spiceworks is emailing SchoolDomain.net addresses and the emails are being rejected because internal service only.

 

So I need to change the mail attributes back to our .uk email addresses to get Spiceworks functioning properly again.

 

But this is going to muck up Office 365 because the mail attribute won't be our tenant address, so it'll change everyone back to being school.onmicrosoft.com

 

So I need to figure out how to change what LDAP attribute Office 365 uses for its email addresses.

 

Does it make sense now?

[Steve21]

I still don't get why you're wanting it that way as it seems to be very much complicating the setup (more than it already is! )

 

You can set spiceworks to use any email address/account to send emails, so you could just set it to use the .net address (So it wouldn't get bounced), or put the .uk address as an allowed one for the .net mail etc?

 

Does spiceworks need to use the .uk one for anything else if everyone is using the .net? As even if you force it for one part it'd break the other if you're using both on spiceworks for different jobs

 

On a complete side note, Microsoft bases it on the proxyaddress attribute too So you can force microsoft to change which is uses as the primary email without changing other bits too. (Capital SMTP takes priority over lower smtp if you want to force it to use one over the onmicrosoft ones etc)

 

Steve

[sparkeh]

On a complete side note, Microsoft bases it on the proxyaddress attribute too So you can force microsoft to change which is uses as the primary email without changing other bits too. (Capital SMTP takes priority over lower smtp if you want to force it to use one over the onmicrosoft ones etc)

Yes, we use this method to set users primary email addresses and any aliases they might have.

[Garacesh]

You can set spiceworks to use any email address/account to send emails, so you could just set it to use the .net address (So it wouldn't get bounced), or put the .uk address as an allowed one for the .net mail etc?

 

Does spiceworks need to use the .uk one for anything else if everyone is using the .net?

Everyone isn't using the .net. Everyone has the .net (and the .org), but staff are still using their .uk one primarily, since it allows them to communicate with parents/agencies and it's the one that they're used to.

They tend to use their chosen flavour of internal services only emails when they need to communicate with pupils (since that's all it's really good for.)

 

I'd like to ditch 365 and our internal host altogether. With Google's infrastructure it would be incredibly easy to make it so that the internal service only rule only applies to kids, and let the staff use their .Org for everything internal and external.

Until you consider the human element, that is. Our staff would, to be diplomatic, not take the transition well.

 

Yes, we use this method to set users primary email addresses and any aliases they might have.

So if I set their mail to .uk to make Spiceworks work again, and set their .net as a ProxyAddress, 365 will still make .net their primary email address instead of school.onmicrosoft.com?

 

Edit: I accept the situation is pretty convoluted. It's really just come about as a series of unfortunate muck-ups and emergency transitions. We ditched Frog because it just wasn't performing, so then we had no VLE. So we looked into 365, since it was free already paid for as part of our volume licensing. 365, it turned out, was up there with Frog as 'not very good', so I started looking at G Suite. G Suite turned out to be a lot better, but by the time I got it set up and ready to go, some of our staff were already using 365, so I can't just turn it off and pretend it never happened.

Edited January 23, 2018 by Garacesh

[sparkeh]

So if I set their mail to .uk to make Spiceworks work again, and set their .net as a ProxyAddress, 365 will still make .net their primary email address instead of school.onmicrosoft.com?

As far as I understand it, yes.

 

Spiceworks should pick up the mail attribute and use this.

If you set the proxyaddress attribute with caps 'SMTP:xxx@yyy' then this should set the primary email in 365

 

Info on how it all works here: https://support.microsoft.com/en-us/help/3190357/how-the-proxyaddresses-attribute-is-populated-in-azure-ad

[Steve21]

Yep should do basically it follows a list of priorities for assigned addresses (Unless it's going to run into another odd if you have all these other ones but should work still as sounds like its syncing ok now)

 

Creates onmicrosoft to provision account

checks SMTP (proxyaddress) for primary

checks smtp (proxyaddress) for secondaries/aliases

falls back to onmicrosoft if none match etc

 

etc

 

That's for Microsoft side anyway, not sure how Google will take proxyaddresses into account but I'm guessing if you said it changes the domain it'll be fine if the usernames are the same across the domains?

 

Can just manually change one to test it though no harm

 

Steve

[Garacesh]

Yep should do basically it follows a list of priorities for assigned addresses (Unless it's going to run into another odd if you have all these other ones but should work still as sounds like its syncing ok now)

 

Creates onmicrosoft to provision account

checks SMTP (proxyaddress) for primary

checks smtp (proxyaddress) for secondaries/aliases

falls back to onmicrosoft if none match etc

Well we don't use ProxyAddresses for anything, so I can't see it being an issue.

 

That's for Microsoft side anyway, not sure how Google will take proxyaddresses into account but I'm guessing if you said it changes the domain it'll be fine if the usernames are the same across the domains?

 

Can just manually change one to test it though no harm

 

Aye, I have some accounts I can test it with, see what happens.

[Garacesh]

Well I've set the mail attribute back to .uk, and let that sync through. The user is now back to school.onmicrosoft.com

I've added SMTP:[email protected] to the proxyAddresses attribute. Waiting for that to sync upstream now. Fingers crossed!

[sparkeh]

The tension is killing me!!

[Garacesh]

The tension is killing me!!

 

I actually have no idea how often 365 synchs. I think it's ≈30 minutes.

[Steve21]

I actually have no idea how often 365 synchs. I think it's ≈30 minutes.

 

Powershell on the AADC server:

 

Start-ADSyncSyncCycle -PolicyType Delta

 

Steve

[Garacesh]

Nope, that hasn't done it.

 

It's put it in as an Alias, but their primary address is still onmicrosoft

 

 

Edit: To clarify, the 'Set as primary' button isn't active, because the account is synched with AD. You can't click it. When an account is synched with AD you're not able to change the properties.

Well, you can, with some crafty powershell, but they get changed back when the sync next runs.

 

On the plus side, Google seems to have completely ignored the proxyaddresses, it hasn't given the test user any aliases, presumably because it's a different domain.

Edited January 23, 2018 by Garacesh

[Steve21]

That's because you didn't read properly! smtp lowercase = secondary, SMTP uppercase = primary!

 

(I jest, but that does make a difference )

 

Steve

[Garacesh]

That's because you didn't read properly! smtp lowercase = secondary, SMTP uppercase = primary!

 

(I jest, but that does make a difference )

 

Steve

 

Shut up, I knew that, I was just testing >.>

 

Yeah, that's worked. That's considerably easier than faffing about with changing Azure's LDAP attributes. Thanks a bunch, guys!