Azure: MFA on Premise switch license model or instance without changing the installation!

If you have an existing Azure MFA configuration running and you don't want to have the double per user cost you need to change your on premise configuration to match the new Azure SaaS MFA service.

In my situation I started to work with "AAD" Premium which automatically also introduced a new MFA provider. Now since i don't want twice the per user fee I decided to reconfigure my existing MFA on premise configuration...

First of al, it will look like you need to reinstall everything but this isn't true. Follow the steps below to reconfigure your on premise MFA to a new MFA ID.

1. login to Azure Active Directory (AAD), and go to the configuration tab in the classic portal (this feature isn't integrated yet in the preview AAD pane in ARM).

2. Open up the link for the MFA Service Provider "Manage Service Settings".

3. In the new windows on the bottom of the page hit the link "Go to the Portal" 

4. Mean while login to your MFA (servers) and go to the installation folder of the Multi Factor Authentication server. (C:\Program Files\Multi-Factor Authentication Server\Data) 

5. Rename the following file  "licenseKey" to "licenseKey.old"

6. in the portal hit the link for download and after that hit the button for generating activation credentials. Copy and paste that information somewhere.

7. Now after you renamed the file on your MFA on premise server(s) start up the management interface. It will trigger the wizard which will allow you top paste the new information you just obtained and reconfigure it to connect to your new MFA Service ID.

8. It will ask your for configuration information like what are you going to use it for and PW info etc. Don't worry you won't lose you're current user population and other settings, those are still there afterwards. It might mean certain users will have to re-register there multi factor mobile app do!

Reacties

Een reactie posten

Populaire posts van deze blog

One ADFS to serve them all (Part I)!

Afbeelding
One ADFS to serve them all (part I)! The goal is to use a vanity URL host names that your site is using and to also use that same host name to resolve ADFS, without having you redirected back to the ADFS original service name (hostname + URL). Because for the end users this shouldn't look like anything else but the vanity domain they are already connected to. Thus how do we solve this? Follow this basic lab entry to get a feeling for the end solution. (I will post more about this subject in greater detail) The ADFS Limitation. The limitation I'm speaking of, in this case is the endpoint for SAML 2.0 / WS-Federation: "/adfs/ls"  (but as you can imagine it's pretty much every endpoint listed in ADFS) We connect with the 1 possible value set during installation for the federation service name: "your.host.name"  Which results in all endpoints only being accessibly under that federation service name.    Figure A: Federation service
Meer lezen

Microsoft Hub NVA configuration example.

Afbeelding
Microsoft Hub NVA configuration example. So in my previous post i gave a short description of implementing Microsoft Hub-Spoke model in IaaS. And i promised to publish some sample code you could use in CICD. Of course the main goal should be to get in to containers and such technologies but seeing as how slow large enterprises are willing to adopt and move to such technologies I'm guessing IaaS will be a standard for some time yet. So I'm going to give you a sketch of a private data center connection via express route (or a S2S VPN instead of the express route) to your azure subscription. And slowly start to explain a few basic configurations. The first overview:      So in this simple drawing you can see I've implemented a express route. I've not drawn a full blown resource drawing so you're bound to miss certain things like a circuit for instance but lets keep it simple. The green line is a express route configuration over whi
Meer lezen

RDS: Remote Desktop Gateway with NPS and Cross domain identities.

This post is about configuring a Remote Desktop Gateway in Resource Domain A while consuming the identities from Identity domain B. Setup: - NPS in Domain A  - RDG in domain A - MFA in Domain A Requirements a "TWO-WAY trust" with selective authentication (or wide if you have no security risks) It won't be possible to authenticate users from domain B in Domain A via the RDG until the computer account has gotten the permission "Allow to authenticate" on the domain controllers in Domain B. The simplest way to achieve this is by going to properties on the "Domain Controllers" OU in users and computers in domain B (RSAT tools) and going to the security Tab. (if you don't see the security tab in users and computers then make sure you've enabled "advanced features" under the view selection.) Then when you're in the security tab click the bottom advanced button. This will open the "Advanced Security Settings for Domain
Meer lezen