Azure AD connect - thoughts?

[DavePa]

We use both on-premise AD and Office365 and at the moment there is no syncronisation between them. At present we do not give students email addresses so it's purely staff and when new users start we create an AD account (for all users) and then, as a separate step, create an O365 account usung the same password if the user is a staff member. Although this is duplication of effort it's easily manageable but I've finally got to the point of wanting to do something about it. The obviousl answer is Azure AD Connect but I want to be comfortable that it's not going to cause issues or incur costs - neither of which is necessarily a problem long term but would need to be factored into any plans.

 

As far as I am aware all passwords are synced - we sync them and prevent users changing their AD passwords although some could have theoretically have changed their O365 passwords. I assume that running Azure AD connect would sync all passwords to Office365 with the AD password taking priority if it is different?

 

Not all users within AD have an O365 account and likewise not all O365 users have an AD account, I wouldn't expect this to be an issue but it's something I need to plan for.

 

Looking further down the line, with an OVS/ES agreement are there different levels of Azure AD (Not the connect part, the full Azure AD) such as free (but limited) and full (but expensive)?

 

Enabling Azure AD connect would make it easy to give students email accounts - at least I think it would - but the problem is that student accounts have passwords that do not meet the complexity criteria. Would I need to change the passwords on all student accounts or would they sync anyway? I know passwords should meet complexity criteria but it has never been an issue as it has only ever been internal AD logons, no O365 has been involved until (potentially) now. We have a steady stream of students unable to remember their numeric passwords so adding in uppercase, lowercase and special characters would be way too complex for many of them. Allowing them to set their own passwords would likely result in some of them using the same password that they use for their banking (we are FE, our students are post 16 and the majority of them have bank accounts). I guess the answer is to allow them self-service password reset of some description and that's certainly something I would need to consider if we are to go with Azure AD

 

Has anybody been in a similar situation but made the plunge? If so, how did you find it?

 

It's early days for us at the moment but I would be interested to hear any experiences (both good and bad) from people who have made, or are considering making, the change.

 

Thanks in advance

[Boredguy]

If you go down the route of AD Azure Connect (the free one) for use with Office 365, you do not have to worry about the password complexity issue as it uses your own active directory password policy (and in fact stops users from changing it via 365 since it does not hold a master copy)

 

Setting it up was very straightforward. Just install the client on a member server, and you can specify which OU's in your domain that you want it to monitor for syncronising accounts.

 

If your AD domain is a different format to your e-mail domain, you will need to add a UPN suffix but again this is covered in the guide.

 

We've been running it now for several years without any issue.

Accounts will not automatically have any licences assigned to them so you can still choose if you want students to have e-mail access or if you just want to use it to provide free Office provision for their use at home.

[dhicks]

If your AD domain is a different format to your e-mail domain, you will need to add a UPN suffix but again this is covered in the guide.

 

As you say, the process was remarkably painless, and the setup process guides you step-by-step. I did find that adding a UPN suffix itself was easy but didn't result in user accounts being synced, I had to set the userPrincipalName Active Directory attribute for each user first. If it's any help, I used a simple .VBS script:

 

Option Explicit
on error resume next

Dim objShell
Set objShell = CreateObject("Wscript.Shell")

Sub listUsers(strOU)
Dim oOu, oUser

set oOU = GetObject(strOU)
For Each oUser in oOU
	' An example of how you might want to set the userPrincipalName value - modify to suite your own needs.
	oUser.Put "userPrincipalName", Split(oUser.Get("userPrincipalName"), "@")(0) & "@YOUREXTERNALDOMAINHERE.com"
	oUser.SetInfo
Next
End Sub

' An example only - replace the string below with an actual Active Directory OU.
call listUsers("LDAP://OU=Teachers,OU=Staff,OU=Users,DC=YOURINTERNALDOMAINNAMEHERE,DC=local")

[DavePa]

Thanks both, looking promising so far

[sparkeh]

As above really, painless to setup and use.

 

My only annoyance is that the auto update feature has never worked for us so I have to keep an eye on our version against latest version. A couple of times it stopped syncing as our version was too old and not supported. It's not too much of an issue though.

[Blue_Cookeh]

We also found the auto update feature wasn't working.

 

Also in the newer versions of the Sync tool Office365 can write passwords back into AD if users change them online. The newest password set will take precedence if they conflict AFAIK.

[Mr_Jiminy]

 

Also in the newer versions of the Sync tool Office365 can write passwords back into AD if users change them online. The newest password set will take precedence if they conflict AFAIK.

 

Has anyone got the write back working? Also, Is ADFS required?

[dhicks]

Has anyone got the write back working? Also, Is ADFS required?

 

If you mean "is ADFS required for the sync tool to work" then no, the tool works fine without ADFS. If you mean "is ADFS required for passwords to be written back" then I'm not sure - we're only using our Office 365 accounts for Minecraft at the moment, we don't have users using it on a daily basis yet.

[sparkeh]

Has anyone got the write back working? Also, Is ADFS required?

ADFS is not rquired: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-passwords-getting-started#writeback-prerequisites

[DavePa]

I've now created a new server and joined it to the domain as a member server. I'm now at the 'Do I push the button and hope for the best or do I ask on Edugeek what will happen' stage....well I was but the fact you are reading this means you can see which way that decision went! My understanding is that as our AD domain is a .college and our email one a .ac.uk that it won't work anyway until I add the UPN suffix. Also, I don't want to synchronise anything except the single OU that I created for the purpose of testing this. Showing my complete lack of imagination this OU is called 'ADConnectTest'.

 

The installer however looks like this:

 

 

If I click 'Use express settings' a syncronisation will happen but I don't want it to! I'm fairly confident that I can skip it later in the process (step 8 on the 'more information' webpage) so I'm probably going to go ahead anyway but my biggest fear is breaking something - I don't (yet) have a lab setup that I can test with so it's all on the live system. Am I likely to cause problems if I proceed beyond this point?

 

Thanks in advance

[3s-gtech]

The UPN suffix being added to AD won't be enough - you'll need to change your users' UPN suffixes to that value. That is a quick, easy and painless process - it shouldn't affect exiting logons or services.

 

I did this just a couple of weeks back. Make sure you carefully select which AD groups to sync (as removing any mistakes can be a time consuming process). Work on getting the O365 Powershell integration working so you can do things like assign licenses quickly. I found that with the newest AD Connect, one of the required PS modules was missing - thankfully I just worked around this.

 

I'd never recommend using Express settings with something like this, as you'll generally need more control. Express settings lead to things like every single service account in your AD being synced, which makes it messier to manage!

[DavetheITguy]

We use AD connect. The new version of it doesn't require ADFS for SSO. You can set this up within the AD Connect program.

[dhicks]

The UPN suffix being added to AD won't be enough - you'll need to change your users' UPN suffixes to that value. That is a quick, easy and painless process - it shouldn't affect exiting logons or services.

 

Just to add that this is exactly the issue we had a few weeks ago, and after changing the UPN suffix for a few test teachers I've not had any issues reported. My worry was that it would somehow affect mail delivery for our on-site Exchange server, but all seems to be fine. I can run a script (see above) to change existing user's UPN suffixs, but I imagine a newly-created user will still use the default, so I need how to investigate changing that.

[3s-gtech]

Do you newly create them much though? Individually at least, I always use Copy which keeps this attribute. In bulk, most tools allow you to choose the suffix IME. No biggie either way.

[dhicks]

Do you newly create them much though? Individually at least, I always use Copy which keeps this attribute. In bulk, most tools allow you to choose the suffix IME. No biggie either way.

 

Hmm - never thought of using Copy, I've always just created users using "Create New User". Our bulk-creation / MIS link needs some work - we use an MIS that no-one else has ever heard of, we need to spend some time sorting out getting data from it properly so it can be used to auto-create new users.

[3s-gtech]

It's not a massive change, but as we use mandatory profiles, have a few custom fields (like Department for O365 licensing and internal scripts) and quite a few groups, using Copy saves a bit of time and means I'm less likely to forget a field.

[MYK-IT]

Thanks @DavePa as your situation is very similar to ours currently.

 

We have been using MS Office 365 for a few years just for our Staff only, and manage by manually creating the accounts within the MS Office 365 portal etc. This has been fine, for now and we are very slowly learning more about the multitude of additional MS Office 365 services (Onenote, OneDrive, Video etc.) that Staff could potentially start using (Full time job in itself to keep up to date with MS Office 365 and what its offers!).

 

I am slowly get a clearer picture of what Azure AD Connect can, and does do; but I would still appreciate some extra advice / confirmation.

 

Azure AD Connect

Best location to install on? (Domain Controller, Dedicated Server (none / domain?) Read somewhere that a member server is required for non-express installation which I think I would need (e.g. selective OUs etc.)

Am I correct in stating that Azure AD Connect allows for the provision / sync from local AD (specified OUs / Groups) to Azure AD; and this in itself does not create / assign Office 365 services (email, ProPlus)? As this will remain an additional process within the Office 365 Admin Portal and / or via PowerShell?

Probably dependent on the previous query; but in relation to the email naming convention, does the email address have to be populated within local AD beforehand, done part of the Azure AD Connect sync or when creating Office365 accounts online?

@dhicks and others have discussed about UPN suffix, can you clarify if that is related to situations like ourselves, whereby our domain is Domain.local and / or it’s to do if local domain name is different from the email domain (naming convention)?

Would l be correct in stating that this setup would allow us to implement Password Sync with SSO?

 

Sorry, I know many will say RTFM but Office 365 is a beast of a product with so many features!

 

OneDriver (Mapper / Migrator)

Also, wanted to thank @garethedmondson & @artfulmatt for the links to OneDriveMapper (which I have not tested yet) but also for the O365Migrator which I have tested, and it works a treat!

 

 

School Data Sync (SDS)

I’ve noticed that @nickbro has already done a lot of work with SDS. This is something that we would like to look at, and introduce further in the year but I am intrigued as to how it all links and associates with all the Office 365 accounts. For example how does it know if Fred Blogs (from SIMS data) is the same Fred Blog in (local AD or) Azure AD; as they would be synched with local AD once we get Azure AD connect working? Hope that makes sense?

 

Does anyone have any hints/tips or best practices that they would not mind sharing, if you are currently using OneNote / Class Notebook etc. in your school? Things like structure, layout. Do you setup one OneNote per subject, year group, class etc.? Permissions. What happens if one staff member creates lots of material and then leaves, how do you take ownership of that content and allow it to remain accessible etc.?

 

I will stop asking many questions, as I could carry on forever as I do think whilst Office 365 is amazing for what it offers to schools for free; it easily justifies a full time support role to attempt get the most of it!

 

Thanks.

Edited January 31, 2017 by MYK-IT

[3s-gtech]

I can hopefully answer most of those:

 

Best location - a DC is fine. Split services as much as you're able and comfortable doing, but it's not a big load on a DC. Use a member server if not a DC.

 

AADC syncs selected users (or the entire forest of users if you don't filter it down). They don't have licenses when synced - you have to use Powershell (or manually assign them, if you have all the time in the world!) but this is straightforward and can be automated.

 

I'm not 100% on this - I'd make sure it's done beforehand just to make things easier for you. We don't use Exchange Online so not sure.

 

The UPN suffix change is for people like you, where your internal domain does not match your external/email domain. You're looking to align the UPN of the users with their email address, which allows O365 to work directly with your AD once the correct DNS changes are made. The UPN suffix has to be resolved to you - your DNS provider will need to add some records for this.

 

This will allow password sync - apparently it will now allow SSO without needing ADFS but we can't do this step as we also need to login to another O365 tenant sometimes.

[MYK-IT]

Thanks @3s-gtech

 

Getting (slowly) clearer!

 

In relation to UPN suffix, is the guide correct? and is step 2 required as well (only ask as found other guides that just list instructions same as step 1)

 

For others that do use email / exchange etc. what about existing accounts (e.g Staff) using Office 365; I assume that they would be listed twice within Azure AD with source as 'Local Active Directory' and 'Microsoft Azure Active Directory' but this would not affect existing Office 365 accounts?

 

I would assume that at some point I would have to (re)associate the existing (manually added) staff accounts to their associated account (as source as "Local Active Directory'?) to enable password sync, SSO etc.

 

Thanks,

[3s-gtech]

That's the guide I used recently, worked absolutely fine. Yes, step 2 is required - it's what actually puts the suffix change into effect. It can be done in bulk easily using tools like ADModify.NET or just doing batches with ADUC.

[MYK-IT]

Thanks again @3s-gtech

 

Is there anything obvious that may 'break' or to look out for when I change the user's UPN suffix? Will it affect logins, or create a new(er) cached profile on desktops? (non-roaming, windows 7) for example?

 

Thanks.

[3s-gtech]

Nope. It will do the square root of nought to logons. It doesn't even affect local Skype for Business accounts if you have them. I struggle to remember the scenarios where it can make any difference - I think it was limited to situations where users were used to logging on with their full UPN (mostly in Windows 10 I believe) obviously having to remember a new suffix. Most of us use the NetBIOS domain name in conjuction with sAMAccountName which is completely unchanged.

[DavePa]

*sigh* so close to getting this working - added UPN, set up the AD Connect tool, made a few tests and all seemed well....then I tried it with an existing user which appeared to work initially but I then noticed that the primary email changed from our one to the onmicosoft.com one. His 'proper' email address is the o365 login as expected but the matching email address is an alias with the @onmicrosoft.com one being the primary. Tried creating a completely new user this morning and their account has created with our domain as the login (good) but with onmicrosoft.com as the default email address (bad). I guess I've probably missed (or messed up) a step, up until that point it had been relatively painless!

[kidpressingbuttons]

@DavePa this happened to me- open a ticket with MS and they will sort it!

[mtillbrook]

from the point of view of wanting to setup emails accounts for the students in the future, in the Ad Connect program on your server, you can tell it which active directroy OU's to sync so, for now, presumably you will only want the staff OU's to sync but then you can add in the students ones later.

 

A word of warning for a mistake I have seen in the past however - if you get it syncing with a specific OU and the take that OU out of the sync - it won't just stop syncing but it will remove those user's email accounts from Azure AD and therefore O365!

 

The only other annoyance i have seen with Ad connect other than things already mentioned was the sync time. I think in the latest version its set as 30 mins and controlled through Powershell. You can change this or manually sync but its all PS now whereas older versions of the Ad sync used a scheduled task so it was much easier!