Author Archive

Global Admin via PowerShell

October 15, 2013

Today I was trying to give a synced Active Directory account, Global Administrator, permissions via the Office 365 portal. Whatever I tried, when pushing save nothing happened.

So I deleted the user from Office 365 using PowerShell (Remove-MsolUser and Remove-MsolUser -RemoveFromRecycleBin ). The parameter “RemoveFromRecycleBin” makes sure that the user is completely removed and no SoftMatching can take place when the dirsync runs again.

After dirsync synced the account again, I still had the same problem, able to give the account User Management, Service Admin, etc credentials but still no Global Admin.

Now there is a way to add global permissions to an account using PowerShell too!! The cmdlet used for that is “Add-MsolRoleMember“. The cmdlet needs two parameters to be able to give the permissions, -RoleName and -RoleMemberEmailAddress. RoleName takes the name of the role which the account should get. In this case that will be “Company Administrator” which is equal to the Global Administrator role in the portal. To get all other possible role names the cmdlet “Get-MsolRole” can be used.

Get-MsolRole output

Get-MsolRole output

The -RoleMemberEmailAddress takes the UserPrincipleName of the account you want to add the role to. The complete command will look like this:

Add-MsolRoleMember -RoleName “Company Administrator -RoleMemberEmailAddress Admin@360on365.com

In my case this cmdlet did the trick and added the needed permissions to the account.

However when the account already has another administrator role added you will notice this warning message in the portal only!

Warning

This can be resolved to select in the portal that the user shouldn’t have admin privileges, save it and run the PowerShell cmdlet again. Or use the Remove-MsolRoleMember cmdlet to remove the unwanted role from the account.

Office 365 Developer Training Kit available

April 19, 2011

We’ve had great news for all infrastructure guys with the release of O365 Public Beta.
Today also great news was released for the Dev guys! Microsoft also announced the “Office 365 Developer Training Kit“.

With the release of this training kit, developers have a great starting point for customizing Office 365.
Not only customizing Sharepoint Online is covered. Also customization and integration of Exchange Online and Lync Online data. 
Think of free/busy, presence, etc. which can be get/modified using API’s.  For some of these customizations you’ll need visual studio, but a lot can be customized without it.

Besides the offline version, there is also an online version named “Office 365 Developer Training Course“.

Some quote’s given by developers who already used it:

“The toolkit gives a quick overview of do’s and don’ts for Office365.”

“It gives a lot of pointers on how to solve common scenarios, like how to build a Workflow Solution (with or without Visual Studio).”

“It is an excellent starting point for both new and experienced developers on Office365.”

Jump in and customize your Office 365 Public Beta account!

HOW TO: Federate your domain with #Office365

March 4, 2011

In the last posts we talked about the enduser experience when using federation. But how do we ‘Administrators’ set it up? Before you start clicking you should remember one very important thing and that is the Active Directory preparation. A lot of companies have their Active Directory domain ending on .local or some variation to that. When you want to federate with #Office 365, your users can’t logon with that domain name. Because domain.local is not resolvable on the internet.

To solve this issue you should give the AD users a User Principle Name (UPN) suffix that matches the domain you want to federate. For example user@fabrikam.com. A best practice is to use the users emailaddress as his/her UPN. Don’t underestimate this step. Depending on your current environment this will be a separate project.

After AD preparation we continue with the creation of a DNS record for the #ADFS2.0 server. In the internal DNS zone of fabrikam.com, create a host record called ‘sts’ which points to your #ADFS2.0 Server.

Now the preparations are done, we are going to install ADFS2.0. In the Server Manager of Windows Server 2008 R2 you also find a version of ADFS, this is however an old version and should not be used in conjunction with #Office365. You can download the correct version here. After downloading the package, run AdfsSetup.exe. After the License agreement page, you’re asked if you want this to be a Federation or Federation Proxy server. The federation server/farm will be installed on the internal network and the proxy server will be placed in the DMZ. So in our situation we choose for the Federation server and proceed with the automatic installation of the following prerequisites:

Before we configure ADFS, we have to create a new domain certificate for ‘sts.fabrikam.com’ and assign it to the default web site on the ADFS server using IIS Manager.
After we’ve done this, it’s time to configure Active Directory Federation Services 2.0. To do this we will follow these steps:

1. Open ADFS 2.0 Management Console
2. In the results pane click on “ADFS 2.0 Federation Server Configuration Wizard”
3. Choose for “Create a new Federation Service”
4. Choose the type of deployment, Farm or Stand-Alone server.

Note: Always use a ADFS Farm in a production environment. When you use a Stand-Alone server you create a hugh single point of failure!

5. Now verify that the correct SSL certificate (the one just created) and Federation Service name (equal to the common name of the certificate) are specified.

The wizard will show a list of changes like the one shown below:

 

Configuration changes set by ADFS Configuration Wizard
Configuration changes set by ADFS Configuration Wizard

After we’ve run the wizard we’ve partly configured ADFS. To fully configure ADFS for use with Office 365 the “Microsoft Online Services Identity Federation Management Tool” and “Microsoft Online Services Connector” need to be installed on the ADFS Server.

- The 32-bit version of the identity Federation Management tool can be downloaded here, the 64-bit version here.
- The “Microsoft Online Services Connector” can be downloaded from the Office 365 Beta tenant. (you need your own Beta account for it).

Install both tools and let the “Services Connector” update your system.  After this step all the preparations are done on the on-premise environment and we can commence the actual federation with Office 365.

The below steps will create a new domain in Office 365 and federate it:

1. Open the Microsoft Online Services Identity Federation Management Tool
2. In the PowerShell window enter: $cred = get-credential (this will show a prompt to enter Office 365 credentials)
3. Enter the Office 365 Admin credentials in the prompt which you want the tool to use for the connection to Office 365
4. Enter:  “Set-MSOLContextCredential -MSOLAdminCredentials $cred” into the tool
5. Then enter: “Add-MSOLFederatedDomain -DomainName “yourdomain.com”

You will see a warning like the one below:

Adding a federated domain

The domain name is now created in Office 365 but it isn’t working yet. First you have to verify that you are the owner of the domain.
This can be done by creating the CNAME record that is shown in the warning you get when performing the 5th step (like the one in the picture above) and point it to ps.microsoftonline.com.

6. Create the CNAME Record in DNS
7. Go back to the Identity Federation Management tool
8. Enter: “Add-MSOLFederatedDomain -DomainName “yourdomain.com” again.

The command in step 8 will read the CNAME record and verify the domainownership. After the domain ownership is verified the domain is federated.
If you would like to review the configuration you can use this command:

Get-MSOLFederationProperty -DomainName “yourdomain.com”

If you already have your domain added to Office365 you have to convert your domain to a federated domain. This can be done by following these steps:

1. Open the Microsoft Online Services Identity Federation Management Tool
2. In the PowerShell window enter: $cred = get-credential (this will show a prompt to enter Office 365 credentials)
3. Enter the Office 365 Admin credentials in the prompt which you want the tool to use for the connection to Office 365
4. Enter:  “Set-MSOLContextCredential -MSOLAdminCredentials $cred” into the tool
5. Then enter: “Convert-MSOLDomainToconverFederated -DomainName “YourdomaininOffice365.com”

After running this command the domain will be changed from a standard authentication to a Federated authentication domain.
This can also be reviewed using the “Get-MSOLFederationProperty” cmdlet.

Have fun federating your domain with Office 365!

#Office365 and #ADFS2.0, how does it work?

December 31, 2010

When you want to create a seamless experience for your users, you can use some 3rd party solution to sync your passwords to the cloud. But do you want to have your passwords stored somewhere else? And let Microsoft authenticate your users? Or do you want to be in control? With #Office365 and ADFS2.0 you can, but how does it work?

First you’ll need to have an On-premise Active Directory. In this directory every user needs a UPN which is resolvable from the internet. So when your on-premise domain is ‘domain.local’ your users need an UPN like: user@domain.nl.

When this is established you can validate the domain in #Office365. It’s a best practice to setup Directory Synchronization first, sync your on-premise users to the cloud, and after that create the federation between the two environments.

To create the federation #ADFS2.0 needs to be installed in the on-premise environment. In test environments one ADFS server can be sufficient, but when it’s going to be used in production a High Available solution is required. Users will heavily rely on this service when using #Office365 , whenever it isn’t available users can’t access the Cloud Services.

Now the Microsoft Online Services Identity Federation Management tool needs to be installed in the on-premise environment. This tool installs a set of PowerShell commands that are used to create and configure federation between on-premise and #Office365. The commands that can be used for this are: Set-MSOLContextCredential, Add-MSOLFederatedDomain and/or Convert-MSOLDomainToconverFederated.

To check the federation setup, the Get-MSOLFederationProperty –DomainName <domain> can be used. This will show all settings for the ADFS2.0 and Microsoft Federation Gateway for the domain entered.

When users now use their corporate computer, they can use #office365 services without getting a new logon prompt. But when they use the services from their home computers the following will happen:

  1. The user goes to the #Office365 portal
  2. User enters its corporate credentials
  3. The credentials are send to the Microsoft Identity Platform and it checks the credentials; it recognizes that it is not the Identity Provider (IdP) for this domain.
  4. The credentials are redirected via the Federation Gateway to the Identity Provider, the on-premise Active Directory.
  5. Active Directory authenticates the user and sends a token back to the Microsoft Identity Platform
  6. The Microsoft Identity Platform will process the token and send it to the web service.
  7. The user is logged on.

clip_image002

With this setup, there is no need to sync user passwords or give any control out of your hands. In a future post we will go into more detail about how to setup ADFS2.0 and #Office365 to use Federation.

Identity management in Office 365

November 19, 2010

As we look at the current BPOS-S platform there are only two options to support user authentication. The first option is to create BPOS-S accounts in the Admin portal by adding a user individually or uploading an excel sheet which contains all the end-users. In this first option there is just one identity being completely managed in the cloud, which is called a MS Online ID.

The second option currently available uses a Directory Synchronization tool (aka DirSync) and can only be used when a company has its own Active Directory. DirSync creates a shadow copy of the current Active Directory user and automatically places the copy into the BPOS-S cloud. The advantages of this solution are that the users and groups can be managed in the local Active Directory and that coexistence can be created between the local e-mail system (Exchange, Notes, or GroupWise) and BPOS-S. The disadvantage of this solution is that an end-user needs to remember two sets of credentials, one for the local Active Directory and one for his/her BPOS-S account.

As we now move on to O365, an additional identity management option will be introduced. This new identity management option will make it possible to set-up a federation between your local Active Directory and O365. Because a federation is created, an end-user will have single sign-on with his/her local Active Directory account to the Office 365 portal, webmail and Microsoft outlook. The end-user experience is so natural; the end-user will not even know that his mailbox or SharePoint site is hosted in the cloud. Because there is a relationship between the local AD and O365, the password policies can be managed in the local active directory and it is no longer needed to support 2 different password policies.

The table below describes all the identity management solution details in O365:

Identity Options O365

Identity Options O365


Follow

Get every new post delivered to your Inbox.

Join 50 other followers