Applies to
This should work on at least Venafi versions 18.x and forward, but has only been tested on 18.x
Symptoms
The most common symptom is a number of errors being logged around AD users in the Venafi logs. These errors don't stop any official processing, but can quickly fill the logs and may even hamper performance.
Related Symptoms can include:
- a blank user in the permissions list of a folder or object in the console.
- Log Errors such as:
IdentityAD - Universal to Name Search for Name Returned No Results
.\VED\Identity\tppad yielded 0 results when searching for [deleted AD GUID]....
- Missing Account information on a Cert
- Other errors in the Entitlement Report
- Email failures for notifications about certificate expirations. This occurs because the email can't be resolved because the AD identity doesn't exist in the domain.
Cause
The most common cause of this is a user being deleted from AD but not from the Venafi product. Other potential causes may be problems connecting to a provider, or an LDAP user who is mostly deleted and thus not resolvable.
Resolution can be tricky. It's not always easy to know what identity is missing. Take a look at the following graphic of a support tab on a cert with a missing identity:
You'll quickly notice that it's not simple to know which account is wrong.
Resolution
Venafi recommends using User Groups for assigning rights in the console. This ensures this problem doesn't occur. For instance, if an AD User Group contains 2 people and one leaves to be replaced by another, the rights in Venafi are still perfectly functional.
Alternate Resolution
Disclaimer: Venafi cautions strongly against any direct DB edits. The following steps do NOT recommend making changes to the Database, but do require queries against the database for resolution.
----------------------------
If you did not use groups as noted above and find yourself in this situation, you can try this. First run the Entitlement Report. This will show you who has rights to what. If you have deleted users, then several of them will only show their AD GUID instead of resolving to a name. Essentially, the unresolved names indicate who has been deleted from AD but still exist in the console. For instance, you may see something like this (AD account GUIDs fabricated):
\Console\UserPrefs\AD+XXXXX AD:AC1930AC1930AC1930AC1930AC1930
\Console\UserPrefs\AD+XXXXX AD:2B52C2B52C2B52C2B52C2B52C2B52C
\Console\UserPrefs\AD+XXXXX AD:9527595275952759527595275952759
Then you can run the following (must be run directly on the SQL server with dbo rights):
select parent, name, classname
from config_contains
join config_objects on config_objects.GUID = config_contains.guid
where
AttributeValue like '%2B52C2B52C2B52C2B52C2B52C2B52C' or
AttributeValue like '%AC1930AC1930AC1930AC1930AC1930' or
AttributeValue like '%9527595275952759527595275952759'
NOTE: Attempting too many "or" statements in the same query may slow the search significantly. The wildcard search indicated is already slow on SQL. We recommend doing this in batches.
The result of this query will show you WHERE in the console these deleted users are. Browse to that location in the console, and delete the users that have no name associated. These are the users that have been deleted from AD.
NOTE: Though a similar effect is had with LDAP integration, it is not quite the same.
If a user is blank, it can safely be removed, or at least SHOULD be removed and a different account assigned instead.
Comments