Popular Post jamesbmarshall Posted June 4, 2013 Popular Post Posted June 4, 2013 Since I know this is a feature close to the hearts of many of you, I thought I'd share this: Synchronising passwords with Office 365 - UK Education Cloud Blog - Site Home - MSDN Blogs 8
plexer Posted June 4, 2013 Posted June 4, 2013 So as long as my users have a upn suffix that matches our office 365 tenant details and I setup this tool I can sync their on prem passwords into the cloud? Ben
AngryTechnician Posted June 4, 2013 Posted June 4, 2013 Yep, just done it here and it's working great.
zag Posted June 4, 2013 Posted June 4, 2013 (edited) Should I be installing this on the domain controller? Also what active directory field am I looking to match it with? Will we be able to use it if our "User Login Name" is different than our email address in AD? Unfortunately our login names use our old .sch.uk addresses Edited June 4, 2013 by zag
AngryTechnician Posted June 4, 2013 Posted June 4, 2013 (edited) It can be installed on a member server. I think you should avoid doing it on a DC since DirSync includes an SQL Server instance, and Microsoft recommend not installing SQL Server on a DC. It will match on the userPrincipalName attribute, which as you probably know is a combination of the user logon name and suffix as shown at the top of the Account tab of Active Directory Users & Computers. Ours didn't match originally either, but if you add the UPN suffix that you use on O365 as an alternate in Active Directory Domains and Trusts, you can then assign the 'correct' UPN suffix to users as needed. This should have no side-effects to any on-premises system, unless you have a third party system with shonky AD coding that doesn't read assigned UPN suffixes correctly. Edited June 4, 2013 by AngryTechnician 2
MicrodigitUK Posted June 4, 2013 Posted June 4, 2013 Since I know this is a feature close to the hearts of many of you, I thought I'd share this: Synchronising passwords with Office 365 - UK Education Cloud Blog - Site Home - MSDN Blogs Excellent news. About time and thanks for posting update on edugeek. Shame this wasn't ready last week when lots of people started live@edu migrations in the holidays. All we need now is the old live@edu 4.5 SSO kit extended for new Office365 customers and small schools (that can't do ADFS) will have a full solution. What are the possibilitys of that @jamesbmarshall ? It's a shame 4.5 SSO kit was only extended to December 2014. So still need to move to ADFS at some point before then. Mabey with a bit of luck Microsoft will extend that support and add in support for new educational 365 customers. Never say never.
AngryTechnician Posted June 6, 2013 Posted June 6, 2013 That depends on your needs. The main thing it doesn't get you is the ability to be automatically logged in to cloud services when logged in to an on-premises workstation (true SSO). ADFS can do that. 1
pantscat Posted June 6, 2013 Posted June 6, 2013 Ok - that's very interesting, thanks. Still trying to work out how/what I need to do to approach our requirements - but I think that's better placed in a new thread!
zag Posted June 6, 2013 Posted June 6, 2013 (edited) Basically... If you want to create users manually -> Use the Office 365 online Portal If you want to manually batch import users -> Export an OU to csv and import online If you want to automatically sync your AD with Office 365 -> DirSync If you want to automatically login a user without typing in their user credentials -> ADFS Edited June 6, 2013 by zag 1
ozydave Posted June 10, 2013 Posted June 10, 2013 Hello Just setting this up. Running the config wizard I get an error 'can't communicate' I know I an using the correct login. I am guessing its firewall related! Anyone know what ports this uses? Cheers
AngryTechnician Posted June 10, 2013 Posted June 10, 2013 Pretty sure it's just HTTPS 443. Is the server behind a proxy? If so, check your proxy logs for entries from the server's IP and see what it tells you. You may need to define an authentication exception. 1
plexer Posted June 10, 2013 Posted June 10, 2013 Can you decide who uses dirsync i.e for testing restrict it to certain users? Ben
jamesbmarshall Posted June 10, 2013 Author Posted June 10, 2013 Can you decide who uses dirsync i.e for testing restrict it to certain users? You can scope by AD OU Just be careful... if you move a user who was sync'd into an OU that's not sync'd then that will cause the Office 365 object to get deleted. 2
ozydave Posted June 10, 2013 Posted June 10, 2013 Pretty sure it's just HTTPS 443. Is the server behind a proxy? If so, check your proxy logs for entries from the server's IP and see what it tells you. You may need to define an authentication exception. Cheers I suppose it also helps if I was not a numpty. I hadn't activated dirsync on 365 control panel!!
Guest Guest Posted June 10, 2013 Posted June 10, 2013 Cheers I suppose it also helps if I was not a numpty. I hadn't activated dirsync on 365 control panel!! Says it can take 24 hours but I activated it today and an hour or so later it was done.
IT-Tom Posted June 13, 2013 Posted June 13, 2013 You can scope by AD OU Just be careful... if you move a user who was sync'd into an OU that's not sync'd then that will cause the Office 365 object to get deleted. How do I specify by OU?
jamesbmarshall Posted June 13, 2013 Author Posted June 13, 2013 How do I specify by OU? I hate to pull out LMBTFY, but here goes! Let me Bing that for you! Configuring the management agent is a simple, but potentially dangerous process. It goes without saying: don't be tempted to fiddle with your production environment otherwise you could end up deleting users by accident or altering the way the MA works into non-supportable state! When you move an object into an OU that isn't synchronised by DirSync it will process the object as a deletion in Azure AD meaning you could lose data. Hope that helps! 1
Speculator Posted June 13, 2013 Posted June 13, 2013 Hi all, Just got this up and running myself. It's not bad, although markedly more convoluted that the Google Apps equivalent (however it does work a little better by not requiring password resets). It's nice that they have an equivalent at all I guess. Setting up AD FS was never something that excited me, but as Microsoft pointed out (I can't remember where, sorry). AD FS is true SSO, whereas this is "same sign-on". I'd imagine that if you want your clients to be able to fire up and logon automatically you're going to need AD FS. Anyway, it's there and it seems to work. It's a shame they couldn't have added in some sensible way to license users automatically though. L8r.
Simcfc73 Posted June 14, 2013 Posted June 14, 2013 Bit stuck, rooting round the internet for SIP and TXT advise. Do these need setting on the internets DNS that hosts my domain name?
Simcfc73 Posted June 14, 2013 Posted June 14, 2013 Think its to do when I set up ADFS previously. Really wish it was as easy as Googles.
Boredguy Posted June 14, 2013 Posted June 14, 2013 Bit stuck, rooting round the internet for SIP and TXT advise. Do these need setting on the internets DNS that hosts my domain name? [ATTACH=CONFIG]18651[/ATTACH] Yes it should be on your internet DNS (in our case the one held by SWGfL) and internally if you have any reference to the same domain name (which we do for seemless redirecting of the FQDN to the local IP instead of traffic going out and back in again)
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now