File size

File size

File size

File size

File size

66.1 MB

Windows Azure Active Directory is described in cartoon format in this video. It's an easy to follow sketch of all the major pieces and how you can use it. It also describes the differences between Windows Azure Active Directory and Windows Server Active Directory.

1) We use Office 365. Does that means I could develop web applications (either cloud based running on Windows Azure or traditional ASP.NET apps running on a hosting provider such as GoDaddy) that could authenticate users using their Office 365 credentials?

2) You mentioned something about one having access to Azure AD services if one is using Office 365. Does that mean I don't have to pay for that and it is all included in the Office 365 subscription? I don't think I have seen any option for managing Azure AD on the Office 365 admin screens; perhaps I am missing something?

2. It was recently announced that WAAD is free. Office 365 licenses, which you apply to WAAD users still have to be paid for, but the users you create in WAAD are free. To manage the users in Office 365 (remember the users are now in WAAD) go to activedirectory.windowsazure.com and log in using your Office 365 administrator account.

Remember the difference between free users in the directory and Office 365 licenses that you have to pay for. A license is then "attached" to one of the free users in the directory. The users are free, the Office 365 services provided to any users are not free.

You can have some users in your WAAD that have O365 licneses applied and some users that don't have them applied.

One question - At about 9 minutes in you say the password is managed and checked by your on-premise AD. So, if I point my application to WAAD to authenticate, WAAD is then asking my on-premise AD to authenticate the password?

I'm looking to switch all of our applications (some cloud hosted) to WAAD to assure access even when our on-premise network (and thus AD) is down/unavailable. If I understood correctly, WAAD still wouldn't be a solution to that problem. Is that correct?

Yes - that's exactly right. In federated environments, the authentication itself is performed by the "identity provider" (IP). It the creates a token which is signed and forwarded to the consumer who trusts it. It means the app and WAAD don't do the password management. That is done by the folks who know it best - the IT admins INSIDE your organisation. If somebody forgets their password, they get it changed in AD. If somebody leaves the org, when you disable their account in AD, they are automatically locked out of not only the AD-integrated environments, but also the environments that are federated with the local AD - such as WAAD based apps.

There's a video which describes the process (using the "old" Ofice 365 directory and apps - exactly the same principles though) here:

A.) - Link the Windows Azure Tenant that sits behind our Office365 environment (xxxx.onmicrosoft.com) with our Window's Azure Account (Owner Live ID/MS Account) so that we see and can manage it through our Azure Portal with our other subscriptions and co-administrators?

B.) - Delete a Windows AD tenant that has been created in the Azure management Portal? I created a test one to see what the process was with every expectation that I could delete it subsequently (no information in any documentation or set-up wizard to the contrary)?

Further to B) above it would also appear that you can only create a single AD tenant per Azure Account, as the option to create an AD directory no longer exists. Is this correct? If so it would be helpful to have some clarity of this in the documentation. I had assumed that I could create multiple Azure AD directory environments, which appears not to be the case.

Can you basically use windows azure in place of onsite active directory to do the following:1. Manage access permissions of users to particular folders on a QNAP Nas?2. Manage users login to computers in the domain, so that it will automatically map network drives, give access to the relevant printers etc?

The channel9 video you linked to above looks as though it should answer NRGfx's question above about managing a current Office 365 Azure AD through manage.windowsazure.com but it in fact does not.

That video states to use your organizational account to log in (which I did) and then to sign up for a trial subscription (which I did). The problem is that this trial subscription created a new .onmicrosoft.com domain which is not the same as our Office 365 .onmicrosoft.com domain. Office 365 accounts are not visible and there is no sign of our Office 365 domains with no way to link them as far as I can find.

If you try to add a "Vanity" domain name to your trial Azure subscription domain that is the same as what you have in Office 365, it will not verify. (I created the requested TXT dns record and over 24 hours later it still will not verify)

The same as NRGFx, I can login to activedirectory.windowsazure.com (with the same Office 365 organization account that I used for manage.windowsazure.com and that I also use for Office 365 administration) and I do see my Office 365 domains and accounts. This site is a preview site (which appears to be going away at some point) and doesn't have full functionality of the manage.windowsazure.com site.

I have a question here. We provide Sharepoint Solutions and Installations for our customers.

We want to install Sharepoint as 3tier farm in an Azure VM and it needs AD for its authentication. But, one of our customers doesnt want to manage AD within Azure VM environment and wants to use Office 365 for SSO. Due to some of the limitations of Sharepoint Online (o365), they want a (on-prem) SP installed (but on a VM).

The question is can we use O365 as identity provider for sharepoint which is installed in one of the Azure Vms?

If no, how can we integrate O365, Sharepoint (on Azure VM) and Azure Active Directory.

I thought I would post the solution to my problem of not being able to access my O365 WAAD through manage.windowsazure.com in case anyone else has run into this. In my case Technical support was unable to assist as I do not have a support subscription to WindowsAzure and Billing support (which Technical support said I should contact as they could link the accounts and correct the issue) said they could do nothing.

I think the problem stems from the fact that we were a Live@edu client which upgraded to O365. I have an organizational account and also a Live ID now. Even though I signed in to manage.windowsazure.com choosing the organizational login option, it appears that any accounts logging in this way that were created pre-O365 upgrade are appearing to manage.windowsazure.com as Live IDs. I verified this with multiple O365 accounts that were created in Live@edu. Of course, a Live ID does not have rights to my O365/WAAD environment and so I am not given the opportunity to see my WAAD.

The solution is to log into manage.windowsazure.com with an Office 365/Organizational account that did not exist in Live@edu (such as the admin@domain.onmicrosoft.com account that is automatically created). Logging in with this account properly (automatically) shows my Office365 WAAD. I then add my desired Live ID to my O365 WAAD and give it admin rights. WAAD lets you add Live IDs to your directory. I then have two accounts, an Organizational and a Live ID, listed in my WAAD directory.

I can then log out as admin@domain.onmicrosoft.com and log back in with my own personal Organizational Account (which is seen as a Live ID for whatever reason) and will then see my trial WAAD (created with the account sign-up process) AND my O365 WAAD!. After the trial ends, I receive a warning that I have no active subscription (the trial WAAD tenant is not visable which is fine) but I continue to see and be able to manage my O365 WAAD.

Jared Pickerell

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.