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.
It’s been years since I started doing coding relating to Exchange ActiveSync out of a curiosity for troubleshooting ActiveSync, and it resulted in me coming out with my first version of the EAS MD utility for diagnosing EAS issues. Since then I’ve expanded the functionality, built an online web-based version, and I also blogged a series of posts on how to implement parts of the EAS protocol. In other words; I’ve learned a thing or two about how to get a mobile device talking to a server
But for a long time not much more has been happening in this space for me. Thing is, once you’ve built a utility that does what it’s supposed to do you can only do so much more before it starts to bloat. I wanted to do something more related to EAS though, but the current approach would only let me go so far.
Another challenge I’ve been having is that I get the occasional request for the source code for EAS MD. Now, a lot of the code has been published in the Exchange ActiveSync Building Blocks series as isolated parts, but the utility itself has not been properly open-sourced. There are different reasons for that, and while I’ve always wanted to help out fellow devs I haven’t gotten around to releasing it yet. (I’m happy to provide code samples, but some of the code is sort of messy.)
So, I came up with a new project aiming to learn more about EAS for myself, as well as open-sourcing the results, and hopefully creating something that benefits other people as well in the process. (I’ll let the readers decide if it’s of any actual value to other people than yours truly.)
I thought I’d take a stab at creating a RESTful EAS API.
Ehh.. Say what?
I recently had a need for enrolling for certificates programmatically from a Microsoft CA, and had to investigate the options available to do so.
In my scenario I would receive a base64-encoded request so I did not have to build the actual request myself. It was just a matter of submitting this to the CA, and getting a base64-encoded certificate back.
NDES would be nicely suited for this task conceptually since it is meant for this type of scenario. However if the client generating the request is not following the SCEP rules it is not possible to submit directly to the NDES server, and you have to wrap the CSR and do some extra work on the server. This is not a bad solution, but with more overhead than I felt ready for right now.
The Microsoft CA also offers up web services for enrolling for certificates, and this would in theory also be an appropriate solution. It’s very flexible, although it turns out the documentation for the SOAP message you need to build is so-so. (You’ll be able to get it right; it just requires some digging on the interwebs.) I was almost there when testing it out, but the enrollment web services requires the template to be included in the CSR. (Enrollment Web Services must be installed on an Enterprise CA, and an Enterprise CA must use templates, and there’s no way I’m aware of to configure a default template.) Since I don’t generate the CSR myself this means I’d have to perform a procedure similar to the NDES approach to generate something the CA would approve of.