Hello
When an author leaves the organisation(therefore creates an unknown user for that person) the user turns into unknown author in the logs… This is not ideal as we then lose the audit trail of the person who made the changes.
Have we set up our ldap or something else incorrectly.
Rgds
Angela
Unknown Author - LDAP
If the user is gone from your LDAP directory, there isn't much we can do. We don't store their information locally; only their unique DN.
If they have just been moved into another part of your tree (like an ex-staff group) then their DN probably changed. If you know the old and new DN, you can remap everything in the system using a script: http://manuals.matrix.squizsuite.net/ldap/chapters/ldap-users#Updating-the-DN-for-an-LDAP-User
This will point all logs to the user's new location and bring their name up again.
[quote]
If the user is gone from your LDAP directory, there isn't much we can do. We don't store their information locally; only their unique DN.
If they have just been moved into another part of your tree (like an ex-staff group) then their DN probably changed. If you know the old and new DN, you can remap everything in the system using a script: http://manuals.matrix.squizsuite.net/ldap/chapters/ldap-users#Updating-the-DN-for-an-LDAP-User
This will point all logs to the user's new location and bring their name up again.
[/quote]
Then how are the logs like 'Asset Status' useful once a LDAP user leaves the organisation. Now we have "unknown user" as in our logs as changing content and no record on the asset on who that was.
[quote]
Then how are the logs like 'Asset Status' useful once a LDAP user leaves the organisation. Now we have "unknown user" as in our logs as changing content and no record on the asset on who that was.
[/quote]
The actual audit trails still contain both their unique LDAP DN and their name as it was at the time. The interface doesn't store all that data and so only has their unique DN, which is likely to contain their username and so may give you an idea about who they were. So the data is still around for auditing, but not necessarily quick viewing.
[quote]
The actual audit trails still contain both their unique LDAP DN and their name as it was at the time. The interface doesn't store all that data and so only has their unique DN, which is likely to contain their username and so may give you an idea about who they were. So the data is still around for auditing, but not necessarily quick viewing.
[/quote]
So how do I as a Sys Admin get access to this information?
[quote]
So how do I as a Sys Admin get access to this information?
[/quote]
Hi Angela,
If you have access to the database, you can get the LDAP user's DN from the internal message table:
"select userfrom, sent from sq_internal_msg where subject = 'Asset Status Changed' and assetid = <assetid you want the logs of>"
Chiran
Ello there,
Yep we have the same issue as well - however we also manually record the users CN as well - so when we get unknown ldap users we can still tell who it is.
[quote]
Ello there,
Yep we have the same issue as well - however we also manually record the users CN as well - so when we get unknown ldap users we can still tell who it is.
[/quote]
How does this work… I am not sure I understand.
It's not accurate but you can help narrow it down a touch as fuzzi says above by when creating the user, recording their whole CN=xxxxxx number, in a spread sheet with their name, and specifically the user group they were in if you can't get hold of a DBA. If their links haven't been removed you they may still show up in the user group as the unknown-user-needle-in-a-haystack?
Is there any possibility that the lookup code that reports 'Unknown LDAP User' could also return the first part of the DN or just the CN?
In looking at the database I found the sq_ast table where the DN seems to be recorded for departed users in the created_userid, updated_userid and published_userid fields on the asset itself.
I'm assuming that Matrix is trying to map the DN against the bridge and failing - but it still has the DN presumably from the database.
'Unknown LDAP User (CN=Common Name,...)' would be more useful than the current 'Unknown LDAP User'.