Home > Office365 > Disable Single Sign On ~~ Convert the federation domain to a standard domain with the PS:cmdlets and Reverse the domain federated authentication settings for the Office 365 accounts.

Disable Single Sign On ~~ Convert the federation domain to a standard domain with the PS:cmdlets and Reverse the domain federated authentication settings for the Office 365 accounts.


office365 Logo

Hi Guys, Smile

Below article provides you step by step guide how to convert the federation domain to standard domain with the PS cmdlets and reverse the domain federated authentication settings for the O365 accounts.

When you configure Single Sign On also known as identity federation with O365 you convert an existing domain from Standard Authentication to Federated Authentication, when you do this the users who are associated with the federated domain can no longer access O365 directly. 

You may have different requirements to covert your domain from Federated Authentication to Standard Authentication. As you can see there are some easy steps to be followed,

 

Log in to your ADFS server and open Online Services Module for Windows PowerShell and enter below shell command,

$cred=Get-Credential 

clip_image002

Once you are prompted with a Windows PowerShell Credential Request enter an Admin Username and Password

clip_image004

Once the credentials are validated enter below shell command, the purpose of entering this to connect to Microsoft Online Service with stored credentials

Connect-MsolServices – Credential $cred

clip_image006

In this command, the placeholder <AD FS 2.0 server name> represents the name of the primary AD FS 2.0 server.

Set-MsolADFSContext –Computer <AD FS 2.0 server name>

clip_image008

It is time to convert your domain from From Federated to Standard Authentication, enter below Shell command, This command removes the Rely Party Trust information from the Office 365 authentication system federation service and the on-premises AD FS 2.0 federation service. The -PasswordFile parameter indicates the path of the text file that contains the newly created temporary password of each formerly federated user’s account.

Convert-MSOLDomainToStandard –DomainName <federated domain name> –SkipUserConversion:$true -PasswordFile c:\userpasswords.txt

clip_image010

Here we go… Smile we just finished the conversion.. now you are good to go… in the below steps I will guide you how to reset the authentication setting for the domain and for each user account to use standard authentication with O365.

Set-MSOLDomainAuthentication -Authentication Managed -DomainName <federated domain name>

image

For this demonstration I will get Susan Baker user name (Directory Synched) to run the below command,

image

For the string value you have enter the username with UPN

Convert-MSOLFederatedUser -UserPrincipalName <string>

image

 

So once the conversion done this will provide the user name and temporary password as above. Now you can go to Microsoft Online Portal and enter the converted username and temp password as below, and follow other instructions in the screen previews,

 

image

image

image

image

Advertisements
Categories: Office365
  1. August 29, 2012 at 4:08 pm

    Hi Dilshan, Nice blog, this is exactly what I was looking for.

    A few questions though:

    -What does the property SkipUserConversion:$true do?

    I want to convert all my federated accounts to standard identity (MSOL) accounts. We want to get rid of dirsync and adfs and our whole AD infrastructure.

    -Can I convert all my users in bulk to standard identity without using Convert-MSOLFederatedUser -UserPrincipalName command?

    Or do I have to manually do this for each user like you did?

    Thanks in advance,

    Kind regards,

    Michiel Quakernaat
    Office 365 Consultant

  2. August 29, 2012 at 5:16 pm

    If the -SkipUserConversion:$true parameter is used, no password file is generated, and the user accounts that are associated with the domain are unusable. That is, the user accounts do not have access to Office 365 resources until the following conditions are true:

    The domain is converted back to use federated authentication by using the Convert- MSOLDomainToFederated cmdlet.

    Each user account is converted to use standard authentication by using the Convert-MSOLFederatedUser cmdlet.

    Hope below link will give the answer for your second question…

    http://community.office365.com/en-us/forums/178/t/54445.aspx

  3. August 30, 2012 at 2:49 pm

    Thanks Dilshan for your quick reply, this is really helpful.

    In our scenario we want to convert every user (20 users) from federated authentication to standard authentication. So we will use the SkipUserConversion:$false -PasswordFile c:\userpasswords.txt to generate the password file and distribute this to every user.

    After that we will deactivate Active Directory synchronization, I read that this process of deactivating DirSync can take up to 72 hours to complete.

    – Do you have any experience with mailbox data loss if we perform those two actions (conversion/dirsync deactivation)? In theory it would not have an impact on data right?

    Keep the posts/blogs coming! 🙂

    Thanks in advance,

    Michiel Quakernaat
    Office 365 Consultant

  4. August 30, 2012 at 10:52 pm

    Yeah Michiel, Deactivating DirSync might take up to 72 hours to complete. It actually depends, it mat take only few hours to deactivate.

    For your second question : I did not experience any data loss after i did the conversion/dirsync deactivation.

    Hope you got the required answer…. Feel free to put your comments…

    Cheers,
    Dilshan

  5. September 3, 2012 at 1:47 pm

    Hi Dilshan,

    We’ve converted last Saturday, it went flawlessly!. Thanks for the assistance. We’ run SkipUserConversion:$false -PasswordFile c:\userpasswords.txt and it generated all the passwords as described. So we converted all the users in bulk to standard authentication.

    After that I’ve disabled DirSync. the process only took 30 minutes (ha ha) to complete.

    Thanks for your quick reply’s,

    Greetings from Holland,

    Michiel

  6. September 3, 2012 at 9:57 pm

    Hi Michiel,

    Glad to here you could do the conversion without any issues…. Please feel free to put any quires…

    We are maintaining 2 forums on FB http://www.facebook.com/groups/o365sl and http://www.facebook.com/groups/405640712806420/.. You can join for it if u like.. You guys are always welcome…

    Cheers,
    Dilshan

  7. September 30, 2013 at 2:29 pm

    http://www.thickbootytube.com
    Howdy just wanted to give you a brief heads up and let you
    know a few of the pictures aren’t loading properly.
    I’m not sure why but I think its a linking issue. I’ve tried it in two different browsers and
    both show the same outcome.

    • November 25, 2013 at 11:58 pm

      Hi it can’t be i have checked with few browsers and it is showing clearly…

  8. Shreedhar Ette
    December 1, 2013 at 5:50 pm

    Hello Dilshan,

    Without converting federated domain to standard. Can I convert a user to standard?

    Your repaly to this is highly appreciated.

    Thanks,
    Shreedhar

  9. December 1, 2013 at 5:57 pm

    What is the purpose of this task. If it is a federated environment standard users can no longer access O365 directly.

  10. Shreedhar Ette
    December 1, 2013 at 6:08 pm

    I want migrate few users from office 365 no federated domain to office 365 federated domain.

    Both domains are hosted in different tenant.

  11. December 2, 2013 at 9:44 am

    You can convert a federated user to a regular user with cmdlet “Convert-MsolFederatedUser”, you should provide a new password for this user. Based on my understanding since you are going to migrate an user to a different SKU in a different domain it is not necessary to convert this user to standard rather than removing the user from the federated tenant.

  12. July 21, 2014 at 12:25 am

    What’s up everyone, it’s my first visit at this web page, and piece of writing is in fact fruitful in support of
    me, keep up posting such content.

  13. July 22, 2014 at 8:22 pm

    Hi there every one, here every person is sharing such
    know-how, so it’s nice to read this webpage, and I used to
    go to see this weblog all the time.

  14. July 23, 2014 at 1:39 am

    I’m not certain the place you’re getting your information, but
    great topic. I needs to spend a while studying more or figuring out more.
    Thank you for fantastic info I used to be in search of this info for my
    mission.

  15. August 2, 2014 at 10:45 am

    Thank you for sharing your info. I truly appreciate your efforts and I am
    waiting for your next write ups thank you once again.

  16. August 11, 2014 at 5:31 pm

    Hi Dilshan,
    What happens if I remove ADFS, but keep dirsync? Is the temporary password still needed, or does it get overwritten if I perform a full directory sync by force?

    I’m looking to convert from ADFS/SSO back to pure password/user account sync instead.

    Thanks,

    Dan Hayward

    • August 12, 2014 at 10:09 am

      Hi Daniel,
      Initially you have to make sure you have the up-to-date direct sync version, so that it supports sync of passwords. If you don’t have the latest version you can download it from Office365 portal and install it on your DirectSync Server. While you doing it you have to make sure you choose sync passwords when you get the question in the installation wizard.
      Make sure you run below command by time you d o the switch,
      Convert-MSOLDomainToStandard -DomainName -SkipUserConversion $false -PasswordFile C:\UsersPassword.txt
      Then you can force password sync, so then user can use their onprem AD user password.
      To do the sync, log in to the DirectSync server and run below PS commands,
      Run C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1.
      Run the following cmdlet
      Set-FullPasswordSync
      Open services.msc and restart Forefront Identity Manager Synchronization Service.
      Your users should now be able to login to O365 with their cloud identity and password, synced from Active Directory.

  17. August 12, 2014 at 9:05 am
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: