Azure Active Authentication

Posted on by
Reply

Details about Azure Active Authentication were released June 12th, 2013:

-Overview on the Azure Identity page: http://www.windowsazure.com/en-us/services/identity/

-Pricing: http://www.windowsazure.com/en-us/pricing/details/active-directory/

-How to manage: http://technet.microsoft.com/library/dn249466.aspx

-How to integrate with your own applications: http://technet.microsoft.com/en-us/library/dn249464.aspx

Excerpt from the last page:

“The Windows Azure Active Authentication SDK allows for you to directly integrate the features of Windows Azure Active Authentication. You can build Active Authentication phone call and text message verifications directly into your applications sign-in or transaction processes. To get started with the Windows Azure Active Authentication SDK see Download”

AAD and O365 Integration

Posted on by
Reply

This post is based on information in the following TechEd 2013 sessions: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/OUC-B341

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B309

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/OUC-B211

There are many sources of information about integrating with Azure Active Directory and Office 365, but to date, they’ve been spotty and the technical details  haven’t really been all that clear. This appears to be changing under the leadership of Program Managers like Jono Luk and Ross Adams. In particular, the OUC-B341 session was excellent and most of the content of this post comes from that session.

Here are some key bits of information I gleaned from the presentations given:

  • new DirSync version is the first version that is upgradable, i.e. after you install this version you won’t have to uninstall and reinstall to move to a new version
  • new DirSync version supports SQL 2012
  • can use same ADFS server for multiple domains, just must use different issuer URIs for each (i think this is documented somewhere)
  • when syncing, if anchor is missing in AAD, then soft-match uses primary SMTP value
  • federated authentication immutableID (or user source address) must match the “sourceAnchor” from DirSync (or whatever you use to create the AAD user)
  • slide showing the authentication flows between clients and O365 and which have a username/password going over them, and more detail about the authentication flows within O365
  • FIM AAD connector will be released to Beta sometime in June via Connect site
  • DirSync is required for Exchange hybrid mode (via a question)

Windows Azure Active Directory and Office 365 TechEd Session roundup

Posted on by
Reply

There were quite a few AAD and O365 sessions at TechEd 2013 this year. As of now, I’ve attended or watched the first five in the list below, and can recommend all but OUC-B209 (unless you are on live@edu currently). I’ll have more posts about the content from these sessions.

Here’s a list:

  • WAD-B309: Introduction to Windows Azure Active Directory. Jono Luk & Ross Adams
  • OUC-B211: Overview of Microsoft Office 365 Identity Management. Paul Andrew
  • WAD-B308: Deep Dive into Azure Active Directory Graph API. Edward Wu
  • OUC-B209: Microsoft Office 365 for Education: Overview and Upgrades
  • OUC-B341: Microsoft Office 365 Directory and Access Management with Windows Azure Active Directory. Jono Luk, Paul Andrews, Ross Adams
  • OUC-B205: Security in Microsoft Office 365. Andy O’Donald, Paul Andrew
  • OUC-B216: Microsoft Office 365 Service Communications. Katy Olmstead
  • WAD-B307: Securing Rich Client Applications Using OAuth 2.0 and Windows Active Directory. Vittorio Bertocci

To view any of these presentations yourself, use a URL of: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/ + the 8 character code I’ve listed. For example: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B309

UWWI Delegated OU Permission Changes

Posted on by
Reply

Back on 5/11/11, we made a minor change to the delegated OU permissions to ensure existing policy was enforced on object creations. This was intended to close a loophole, and we didn’t anticipate any impact to customers. But we ran into two customer impacts.

First some background:

We’ve never granted the ability to ‘change permissions’ at the top level of your OU. However, by allowing folks to create objects, we give them the ability to be the object owner. In either AD or NTFS, an object owner has two implicit permissions that *aren’t* explicitly in the ACL. These two permissions are:

  • Modify Owner
  • Change Permissions

In other words, the owner can make a different account the owner, and the owner can also set permissions on that object.

Since we allow delegated OU admins to create objects, they become the owner, and inherit the ability to set permissions. That is, prior to 5/11/2011 they could set permissions.

With WS2008, Microsoft provided a way to override the implicit permissions that an owner has. This can be done via the new “well-known sid” security principal called NT Authority\Owner Rights. If that principal is granted anything on an object, it overrides the implicit permissions.

So on 5/11/2011, you’ll see in the documented perms, that we’ve set “Allow ‘Owner Rights: Modify Owner”. This means that an object owner still can pass the ownership, but doesn’t have the ability to change permissions.
We didn’t think this change would mean much to everyday use, but it turns out it did.

Our first problem was with an ACE that the Active Directory Users and Computers tool puts in place–trying to be helpful. For example, when you create an OU, you may see a checkbox labeled “Protect container from accidental deletion.” When checked, that results in an inherited ACE applied to the OU. UWIT creates all the top-level delegated OUs, and on about 80% of those we checked that box. Prior to the above change, that didn’t cause a problem when an OU admin went to create a child OU because the creator/owner could still set the inherited permission on the child OU. But after the above change, this ACE would prevent the child OU from being created. We’ve since removed the problematic checkbox on all top-level delegated OUs, so this isn’t a problem moving forward.

The second problem was with delegating who could join a computer to a computer object an OU admin created in their delegated OU. Yep, as you probably can guess, with owner perms, prior to the change this was no problem, and after the change, this was a problem. In this case, the (computer) object was created, but the ACEs representing join perms were only set to the creator/owner, not what was specified. And no error message is raised about Active Directory Users and Computers failure to set the desired join permissions. We’ve fixed this problem by granting OU admins the ability to modify permissions on computer objects, and you’ll see that represented in the documented permissions too.
So in both of those cases, the behavior prior to 5/11/11 is in effect.

Finally, I should mention one other delegated OU permission change we made on 5/11/11. Because we grant pretty broad permissions, prior to 5/11 it was possible for OU admins to rename their delegated OU by themselves. But now they can’t rename their top-level OU. We don’t object to a name change of your top-level OU, but there are implications based on the many namespaces that are linked to that OU name. So we’d like to be involved in name changes of that top-level OU to ensure that everything dependent on that name is properly adjusted.