Tag: LDAP

How to fix NCSECDESC Failures in Active Directory after DCDiag reports a failure.

How to fix NCSECDESC  Failures in Active Directory. If you get the following when running DCDiag on a Windows AD Server do the following to correct.

 

Starting test: NCSecDesc
Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn’t have
Replicating Directory Changes In Filtered Set
access rights for the naming context:
DC=ForestDnsZones,DC=MYDOMAIN,DC=local
Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn’t have
Replicating Directory Changes In Filtered Set
access rights for the naming context:
DC=DomainDnsZones,DC=MYDOMAIN,DC=local         …………………….
MYHOST failed test NCSecDesc

 

Download fixfsmo.vbs and find or download ADPREP for your distribution of windows.

First run “cscript fixfsmo.vbs DC=DomainDnsZones,DC=MYDOMAIN,DC=local ” Change only the domain name to match domain, leave [DC=DOMAINDNSZONES]

Next  run “cscript fixfsmo.vbs DC=ForestDnsZones,DC=MYDOMAIN,DC=local ”  Change only the domain name to match domain, leave [DC=FORESTDNSZONES]

Next locate your ADPREP directory and change to\adprep,   now run  adprep /rodcprep . If you do not have the ADPREP tools you can get them from Microsoft’s website or on the original CD media your server came with.

Then rerun DCDiag to verify that the failures are gone.

 

 

Enjoy,

Cubert 😎

 

DCDiag fails with the host could not be resolved to an IP address check the DNS server, DHCP, server name, etc although the guid dns name couldn’t be resolved.

You run DCDiag and it returns a failure that names can not be resolved.

  
   testing server: default-first-site-name\mydomain
      starting test: connectivity
         the host 7397e120-1c8d-4f2d-b8cb-d829d16d949a._msdcs.mydomain.local could not be resolved to an
         ip address.  check the dns server, dhcp, server name, etc
         although the guid dns name
         (7397e120-1c8d-4f2d-b8cb-d829d16d949a._msdcs.mydomain.local) couldn't be
         resolved, the server name (myhost.mydomain.local) resolved to the ip
         address (192.168.1.5) and was pingable.  check that the ip address
         is registered correctly with the dns server. 
         ......................... myhost failed test connectivity

 

This is mainly due to bad or non existent DNS records on your AD server. Here are the steps to run through to make sure your Active Directory DNS has the correct records needed to allow Active Directory to function correctly in a Windows 2003 or Windows 2008 environment.

 

Steps to resolve:

  1. Verify SRV Records
    http://support.microsoft.com/kb/241515

  2.  SRV Records missing after Promo
    http://support.microsoft.com/kb/241505
  3. Verify All DC’s are point to one as “master”, Second to them self or another is better.
  4. Verify DHCP Client Service is running (needed for Dynamic DNS updates)
  5. Run at cmd prompt -> net stop netlogon && net start netlogon
  6. Run at CMD prompt -> netdiag /fix

  7. Re run at CMD prompt ->  DCDiag.exe 
You should now get a passing test when you run dcdiag.exe. You may see the following response to the dcdiag.exe execution.
Testing server: Default-First-Site-Name\MYDOMAIN
Starting test: Connectivity
*** Warning: could not confirm the identity of this server in
the directory versus the names returned by DNS servers.
If there are problems accessing this directory server then
you may need to check that this server is correctly registered
with DNS
……………………. MYHOST passed test Connectivity

 Enjoy
Cubert  😎

Quick and Easy Setup of Active Directory Authentication for VMware vSphere 5.1 SSO (Single Sign On)

VMware vSphere vCenter Server 5.1 now uses a new SSO (Single Sign On) service to authenticate with Microsoft Active Directory when deploying vCenter. If you do not install this services and configure it for AD then you will not be able to use your domain accounts with vCenter 5.1  During the initial install you may get errors when installing SSO.  KB 2034374 reports that a error of  ” Error 29155 Identity source discovery error”  is due to a failed attempt to automatically discover your Active Directory domain. Verify that the domain name and DNS are setup correctly.

Now lets setup an AD server in vCenter to allow our Domain Accounts. First we will login to vCenter Web Client (https://127.0.0.1:9443) if you used the default ports for the web client installs. The default login is admin@system-domain  and the password you set for SSO during the install process. Once you are logged in to the web client you can continue.

Now Select [Administration]

vCenter SSO-login

 

 

 

 

 

 

 

 

 

Now Select [Sign-On and Discovery] -> [Configuration]

SSO Configuration

 

 

 

 

 

 

 

 

Under the Identity Sources Tab in the right pane select the PLUS symbol to add a new AD source. This will pop up a “Add Identity Source” window, select the active directory radio button and fill out the requested information with you AD Domain name and the “OU” the holds your users and groups.

Here is the generic information you will need just replace the sesenviron.local with your domain and then place your AD credentials at the bottom.

Adding identity source

 

 

 

 

 

 

 

 

 

 

Now that we have a AD server assigned as a source we must now add this newly created connector to our “Default Domains ” list.

Add AD to Default Domains list

 

 

 

 

 

 

 

 

Now that we have it in our Default Domains list lets move it up to be our primary source. To do this highlight the AD domain name and select the blue arrow head pointing up and move the domain name to the top of the list .

Set priority of the domains

 

 

 

 

 

 

 

 

 

 

Now lets select the small floppy disk icon to save the changes to the default domain list box. Once this is complete we should be able to open up the vSphere client application and log in with domain access. You should be using a domain level admin to access vCenter.

 

I hope this helps some people out there.

Cubert 😎