One of the components I highlighted as an improvement to the MDM enrollment process in Windows Phone 8.1 was support for Web Authentication Broker (WAB):
Which itself was “ripped” from the Windows 8.1 bits:
At any rate; it is a nice way to hook into Azure Active Directory, and by extension your on-prem AD as well if you’re doing DirSync. (Or ADFS if you are so inclined.) What I used in the MDM process was the .Net server side implementation suitable for browsers.
Unfortunately using WAB natively in Windows Phone was not as easy. Yes, the WAB component is present in the operating system, but it requires some effort to get started with nonetheless. Active Directory Authentication Library, or ADAL for short, was/is the package responsible for making AD integration easier in .Net server side and now it’s finally present for Windows Phone 8.1 as well. Now you can easily use AD as your authentication in your Windows Phone app without problems, without VPN/reverse proxying and all that stuff. Just include the necessary NuGet package in your VS solution and you’re almost there. (Yes, you still need to write some code yourself.)
The funny thing is that this library was available for iOS and Android before Windows Phone even though Active Directory is just about as Microsoft as you get technology wise, but now you should be golden whatever your mobile preference is
Usually I’d whip up some code for you to try this, but in this case I will let the work already done by Vittorio Bertocci illustrate the moving parts instead. There’s a nice code sample over on the official AzureAD GitHub page:
Not to mention a blog post with some more details:
Short post, I know, but useful little trick I hope.
I ran through a setup three weeks ago where I used the “Directory Extensions” preview feature in Azure Active Directory to show how I could store an extra id on the user object and use this attribute in a different web app:
Not feeling entirely done with creating samples I’ll be building another web app showing another scenario where directory extensions might be a useful approach. We’ll extract some data from Office 365 (Exchange Online more specifically), and insert into Azure AD and re-use it.
Exchange Online has this neat feature where you can publish your calendar externally so anyone can check it without being a member of your Active Directory. Actually, it’s not just Office 365 users who get this – Exchange 2013 on-prem can do so as well, but this sample will only explore the clouded version. (You can probably tweak it to work with a local Exchange Server if you like; the differences are probably fairly minor.) I’m not saying there aren’t drawbacks to using this feature, you certainly should not expose all details in your calendar to the general public, but it can be useful in a couple of scenarios and you don’t have to share all the details either.
Way back in September 2012 I built a lab for supporting IPv6, and running basic connectivity tests for mobile devices:
The conclusion back then was that iOS supported IPv6, Android was very dependent on the build you had on your device, and Windows Phone didn’t support IPv6. Well, it sort of supported it, but in a half-baked way. I was able to have a Windows Phone 8.0 device acquire an IPv6 address through DHCPv6, but never got it working for any practical purposes since it didn’t support SLAAC. Short recap, (read the original blog post for all the details), SLAAC was required back then in a Windows environment to actually get online. I don’t know if this is different with Windows 8.1/2012 R2.