vCenter Domain Authentication

Posted on 09/03/2024 by PeteLong

vCenter Domain Authentication KB ID 0001854

Problem

Note: This procedure uses vCenter 8.0 Update 2, (the process is the same for vSphere 7).

When you setup your VCSA you will have configured SSO, in most cases accepting the default SSO domain of vsphere.local. But If you want to log into VMware you probably want your identify source to be AD (to use you existing usernames and passwords).

Note: In this example I will grant administrative access to the domain admins group, in production you probably will want to create some new AD groups and look at the principles of least privilege.

Solution: vCenter Domain Authentication

Once logged into vCenter, changing views is done by clicking the ‘three lines’ at the top left of the screen, navigate to Administration > Single Sign On > Configuration > Identity Provider > Active Directory Domain > Join AD.

Supply the domain name and some credentials that have the rights to join a machine to the domain > Join.

Nothing Happens! Don’t worry that’s normal, nothing will change (and you can’t’ progress) until you’ve rebooted the VCSA.

While its rebooting you can check in you AD and you will see the computer object has been created for the VCSA.

Have some patience, once the VCSA has rebooted and all the services are back online you will see the display has changed to show the domain information, you can now proceed.

Identity Source > Add.

Change the drop down to Active Directory over LDAP.

Enter the details to join the domain, the account you use to ‘bind’ to active directory can be a simple ‘domain user’. Fill in the fields and select ‘Add’.

Now select the domain you just added and ‘set as default > confirm by pressing ‘OK’.

Users and Groups > Groups > Select Administrators > Edit.

Change the domain to your AD domain > Search for Domain Admins > Add that group.

You can now authenticate into the VCSA with an account thata is a member of that AD group.

Azure AD Connector: Disable ADFS Authentication

Posted on 24/01/2020 by PeteLong

KB ID 0001643

Problem

Why would you want to disable ADFS authentication? Well what if ADFS is down, or you want to revert to some other authentication method? I was in a position a few weeks ago where I needed to disable ADFS on a clients Azure AD Sync. At that time the Microsoft Tech on the phone steered us towards doing what I can only describe as a ‘forced de-federation’. This involved using Powershell and it resets the password on all the ‘cloud’ accounts and puts those passwords in a text file.

[box]

Convert-MsolDomainToStandard -DomainName {Federated-Domain-Name} -SkipUserConversion $false -PasswordFile c:\password.txt

[/box]

BUT YOU DON’T NEED TO DO THAT!

I need to migrate the same client to ADFS in the near future, so I wanted to investigate what to do if I had a problem in future, “How do I roll back?” and more importantly “How do I limit disruption if theres a problem?“

So I built it on the test bench, and did it myself.

Solution

To disable ADFS you need to substitute it for something else, the most common (and easiest) options to work with are ‘Password Hash Synchronisation‘ or ‘Pass-Through Authentication’. I’m going to use password hash synchronisation, but I will also link to pass-through authentication, if you prefer that option.

First job, is to make sure you are on the newest version of Azure AD Connect you can get your hands on. Older versions will not have the options you require. The version you see below was the newest at time of writing.

Then we need to enable password hash synchronisation > Launch Azure AD Connect > Configure > Customise Synchronisation options > Proceed to ‘Optional Features’ > Tick ‘Password Hash Synchronisation’ > Complete the wizard.

WAIT! Let your AD replicate the password hashes, I usually just Force a Delta Azure AD Replication. Then you need to swap from ADFS. Launch Azure AD Connect > Configure > Change user sign-in > Next > Tick “Password Hash Synchronisation’ > Accept the warning > Next.

Note: Yes I saw the warning too, but I had users logged into Outlook etc, and no-one was re-prompted, and no-one was refused authentication. Even so, If you are concerned you might want to do this on a weekend, or after hours.

OK what about ‘Pass-Through Authentication”? If you want a long term scalable ADFS replacement this might be a better option for you, there are some hoops to jump through, and a bit more planning and forethought. See the following article for an explanation;

Azure Pass-through Authentication

Because we are enabling single sign-on, you will be prompted for a set of local domain admin credentials > Complete the wizard.

Then force a Delta Azure AD Replication.

Cant login to vCenter after upgrade to 5.1

Posted on 17/11/2015 by Migrated

Error 29155. Identity source discovery error

KB ID 0000679

Problem

Note: I’ve had the same problem on a freshly installed vCenter 5.1 as well.

I upgraded my Virtual Center from 5.0 to 5.1 yesterday, and post upgrade I could no longer login, it would tell me “Unknown user or bad password”.

During the upgrade I did see this error, but after that the install completed successfully.

Error 29155.Identity source discovery error

As it turns out this was the root cause of my problem.

Solution

1. Firstly install the ‘Web Client’ on the Virtual Center. Note: You will need Adobe flash installing for this to work. (Sometimes this needs a reboot, and the firewall turning off, and/or adding to trusted sites in IE, before it works).

Note: The Web Client is on the Virtual Center install CD.

2. Connect to the the server on https://localhost:9443 log on (Note: Use the username of admin@System-Domain and the password you used when you installed Single Sign on earlier). Expand Sign on and Discovery > Configuration > Select the ‘Add’ icon.

3. Supply your domain details as follows, those ldap URL’s simply point to the domain controller(s).

4. Scroll down and enter the domain logon credentials, then select ‘Test Connection’.

5. It should say connected successfully, if not check the comms and the details you entered are correct.

6. Click the ‘Add to Default Domains’ Icon.

7. Finally save the changes by selecting the ‘Save’ icon, you should now be able to authenticate to the vCenter with your domain credentials.

Configure Wireless Network Stings via Group Policy

Posted on 17/11/2015 by Migrated

KB ID 0000923

Problem

If you have a corporate wireless network, you can send the settings out to your clients, rather than have them all ask you what the wireless settings are, and how do they connect.

Here I’m going to use Domain group policies, but the procedure is the same for local policies (just run gpedit.msc instead). And the dialog boxes are exactly the same as if you were configuring them on the client machine. (You can import the settings form a working client if you like).

Solution

1. On a Domain Controller > Administrative Tools > Group Policy Management Console > Navigate to an OU that contains your computer objects and either create a new GPO, or edit an existing one.

2. Navigate to;

[box]

Computer Configuration >
Policies > Window Settings > Security Settings > Wireless Network (IEEE 802.11) Policies > Create A New Wireless Network Policy for Windows Vista and Later Releases

[/box]

3. Give the policy a name and add in an ‘Infrastructure’ type network profile.

4. Name the profile > Add in the SSID of the wireless network > Security Tab.

5. Set your authentication type, here I’m using WPA2/AES.

Optional

6. Here I want my client computers to see the wireless network, before the users log on (so that their logon scripts will run and their drives get mapped) Advanced > Enable Single Sign On > OK.

7. Properties > Remove the tick from ‘Validate server certificate’ > OK.

Note: I’m configuring for use with an HP MSM controller, if I leave this option ticked, I will have to upload the CA Cert from my domain, into the controller, or clients cannot join the wireless network.

8. I’m not making any changes to the Network Permissions tab > Apply > OK.

9. Now either wait a couple of hours, run gpupdate /force on a client, (or reboot it).

PeteNetLive

Technology that 'Just Works'

Tag Archives: Single Sign On

vCenter Domain Authentication

Problem

Solution: vCenter Domain Authentication

Related Articles, References, Credits, or External Links

Azure AD Connector: Disable ADFS Authentication

Problem

Solution

Related Articles, References, Credits, or External Links