locked
Should there be default Access Control Policies in ADFS 2016 after a migration and FBL raise? RRS feed

  • Question

  • I have a WID based farm, migrated over from ADFS 2012 (3.0) to ADFS 2016. When I ran Invoke-AdfsFarmBehaviorLevelRaise it threw an error trying to restart the service on a remote server, this was after completing the upgrade of the databases on each server successfully.

    I tried to run the invoke again, but it tells me the environment is already at the right level (which checks out with Get-ADFSFarmInformation, CurrentFarmBehavior = 3) for all 2016 servers. I had to manually restart the adfssrv service on the remote server that failed and on the primary after this and everything is working fine. All my trusts are Ok etc.

    However in all the documentation I have seen there are a set of default Access Control Policies listed (such as Permit Everyone) and some default Scopes appear to be created also. My environment does not have these, I am not sure if this is because I did a migration or because the Invoke-AdfsFarmBehaviorLevelRaise didn't quite complete.

    Has anyone done a migration and FBL and come across the same thing when it comes to ACPs and Scopes? Or is this likely a task that was not completed during the FBL?

    Edit: It does indeed look like there should be some there by default, there is a column "Built-in" with Yes noted against ones like "Permit everyone" in screenshots I can see for others. I'm thinking I might need to raise this with Premier unless anyone has any tips? 
    Sunday, April 30, 2017 2:27 AM

Answers

  • Figured this one out! If you get this issue, then don't carry on using a half-upgraded farm. Downgrade the FBL using the Restore-AdfsFarmBehaviorLevel cmdlet, then Invoke-AdfsFarmBehaviorLevelRaise with the -Force switch.

    This will override the first 2016 FBL db that was created with a new one based on the previous 2012R2 FBL db. Hence why you should check this before you go ahead and make other changes in your farm, those other changes will be overwritten.

    Doing this and having a successful run at raising the FBL will ensure that you properly upgrade and will insert the builtin scopes and ACPs.

    Sunday, April 30, 2017 6:09 AM

All replies

  • Figured this one out! If you get this issue, then don't carry on using a half-upgraded farm. Downgrade the FBL using the Restore-AdfsFarmBehaviorLevel cmdlet, then Invoke-AdfsFarmBehaviorLevelRaise with the -Force switch.

    This will override the first 2016 FBL db that was created with a new one based on the previous 2012R2 FBL db. Hence why you should check this before you go ahead and make other changes in your farm, those other changes will be overwritten.

    Doing this and having a successful run at raising the FBL will ensure that you properly upgrade and will insert the builtin scopes and ACPs.

    Sunday, April 30, 2017 6:09 AM
  • I had the same issue with SQL DB. 

    Don't quite remember why it happened but i think it was because of company policy that mandates very restrictive User Rights Assignment permissions. During the FBL the 2016 ADFS Service wouldn't start and wasn't able to complete. I added the necessary permissions and was able to start the service. Everything looked fine, all relying party trust were there but later on I noticed that I had absolutely no Access Policies.

    The old ADFS 3.0 ADFSconfiguration DB has been deleted from the SQL Server so I can't give it another go any more so l will have to see if I can simply create them manually or if that will have other implications.



    Friday, March 23, 2018 5:16 PM