This is the beginning of a little standalone identity management project me and Kevin are working on for IPSwitch's WhatsUp Gold product.
This "WhatsUp Enterprise New User System" aka WENUS enumerates a configured LDAP Group (and any nested groups) for user accounts--any users that do not exist in the WhatsUp are created automatically. It also reads the user account's department attribute and creates access to the device group that has a matching device group description. In our case we have ~200 remote sites, at each of those sites there are up to 2 techs who use WhatsUp to monitor systems at each site. These remote sites are broken out into Device Groups, we populated all the device group description fields with the corresponding site/dept code--which is also populated in the user account's LDAP department attribute. This script can be run nightly or weekly to ensure the proper folks get access to only their respective area. Furthermore it outputs to the WhatsUp System Activity Log, so you can see new users being created, and any errors there.
This was written for WhatsUp Gold v15 but should work on older versions--perhaps requiring slight modifications.
- Enumerates a LDAP Group (and any nested groups) to create WhatsUp User Accounts when additions are made to the group
- Scopes WhatsUp Device Group Security based on Department LDAP attribute & Matching WhatsUp Device Group Description fields
- Outputs to the WhatsUp System Activity Log - any Creates and any Errors are logged centrally.
Couple of my buddy's just threw this blog up: http://desktopengi.com. Check them out, they have a very strong focus on Desktop Engineering/DevOps.
Some of the things you will find there:
- Scripts to assist with a Google Apps Migration/Support Google Apps Long-Term
- A Clean Login Script to handle multiple drive mappings on a per dept basis that ingests data from OUs and CSVs making changes a snap
- Identity Management Scripts - Automation of Sec. Groups, etc.
- *Very* Comprehensive Shortcut creation script--good for software deployment folks
So your trying to import a signed certificate that was created with the certificate signing request (CSR) you get an error in vCenter Orchestrator Configuration about the cert not being the correct format. If your using Microsoft Active Directory Certificate Services here are the exact steps:
- Export a certificate signing request from the VMware vCenter Orchestrator Configuration: Server Certificate area (goto http://vco-server:8282 then click Server Certificate on the left). If this option isn't displayed select the option to install a self signed certificate and then you will get the option to export a certificate signing request.
- Copy and paste the contents of the CSR file you downloaded from vCO Config area to your Cert Server web interface (http://CERTSERVER/certsrv).
- Select Web Server from the drop down and submit.
- Now ensure DER encoded is selected and download the certificate chain.
- Change the file extension on the file you just downloaded from .p7b to .csr
- You should now be able to upload it immediately using the "Import certificate signing request signed by CA" option inside the VMware vCenter Orchestrator Configuration: Server Certificate area (again goto http://vco-server:8282 and select Server Certificate on the left)
- You get a green bubble by Server Certificate and everything is happy.
So a user account is getting locked out from your vCenter server? Check the windows security event logs, they typically clearly point out the culprit. If they are not much help you can start with the common things that are applicable for any server causing account lockouts:
These can be running under the locked out user account
Persistent Drive Mappings
Using the locked out user account credentials
Disconnected TS/RDS Sessions
A process can be running that is using the locked out user credentials
Ensure you did not use the user account that is being locked out for an ODBC connection for the vCenter database
Scheduled task(s) can be setup to run as the locked out user
Once you've exhausted all of that...
VMware Specific Areas to Check
Can be running with out of date credentials and caused the lockout, you can use the sessions area in vCenter to check for active sessions
Uses a specified user account to poll servers to see if they are good candidates for virtualization
Has a proxy configuration area you can define a user account to login to the proxy with
VMware Data Recovery
Data Recovery uses stored credentials to connect to vCenter, ensure the specified user isn't the one being locked out
NetApp's Vitual Storage Console
I don't think there is specifically a place you can have cached credentials in here, but I registered this to my vCenter using my account and it ultimately ended up locking me out about a month later when I changed my password due to expiration
Look at any Monitoring Tools (especially trials and free utilities you may have forgotten about) you ever installed on the box that might be running with the locked out user account: Veeam tools, vKernel tools, Vizioncore tools, Quest vFoglight Quick View, etc. You can always disable services and wait to see if the lockouts continue if you really get stumped.
The official VMware KB 1006996 on virtualizing existing domain controllers recommends 4 options (simplified below):
- Demote the DC via dcpromo, do the conversion, then promote the DC back again using dcpromo--With all that trouble why not just build a new one?
- Cold Clone--Cool, except if I'm working remote I need a working out of band management solution to boot the DC with the ISO...or setup a PXE server to provide a bootable cold clone image to do this, regardless too much extra leg work.
- Use Directory Services Restore Mode (DSRM) and do a hot conversion, cool, but now I need to reboot these guys and hope someone remembers the DSRM password, or reset it before hand...
- Get rid of the old DC via dcpromo and build a new VM and promote it--no conversion at all, wait what?
Having to P2V over a hundred DCs we didn't particually like any of these options, the KB focuses on the possibility of a corrupt NTDS.DIT if you don't follow any of those recommendations. For our first few we did the DSRM route: