Hi Chis,
a very good question and yes you are correct, the reqauthzid is mapped to the
connection pool's ldap userid.
Of course this isn’t really helpful if you’re trying to figure out who the end
user was doing the admin functions. For that we must understand how fortress
stores its administrative contextual info so we must have a look at one of the
aux obj classes:
## AC4: Fortress Audit Modification Auxiliary Object Class
objectclass ( ftAxId:4
NAME 'ftMods'
DESC 'Fortress Modifiers AUX Object Class'
AUXILIARY
MAY (
ftModifier $
ftModCode $
ftModId
)
)
which can be attached to ldap mods automatically whenever audit has been
enabled in the fortress properties. It uses data contained from within its
base logical entity:
public abstract class FortEntity
{
protected String modCode;
protected String modId;
@XmlTransient
protected Session adminSession;
protected long sequenceId;
@XmlTransient
protected String contextId;
One trick: The internal userid is mapped to ftModifier attribute instead of
external one. (something that should perhaps be discussed further)
A screenshot on slide #40 shows the raw ldap audit data mappings:
http://schd.ws/hosted_files/apacheconeu2016/db/Apache-Fortress-ACEU-2016-v2.pdf
and here is the data provider’s method that sets the values onto the ldap entry:
public abstract class LdapDataProvider
{
...
/**
* Add the audit context variables to the modfication set.
*
* @param mods used to update ldap attributes.
* @param entity contains audit context.
*/
private void audit( List<Modification> mods, FortEntity entity )
{
if ( !Config.getInstance().isAuditDisabled() && ( entity != null ) && (
entity.getAdminSession() != null ) )
{
if ( StringUtils.isNotEmpty(
entity.getAdminSession().getInternalUserId() ) )
{
Modification modification = new DefaultModification(
ModificationOperation.REPLACE_ATTRIBUTE,
GlobalIds.FT_MODIFIER,
entity.getAdminSession().getInternalUserId() );
mods.add( modification );
}
if ( StringUtils.isNotEmpty( entity.getModCode() ) )
{
Modification modification = new DefaultModification(
ModificationOperation.REPLACE_ATTRIBUTE,
GlobalIds.FT_MODIFIER_CODE, entity.getModCode() );
mods.add( modification );
}
if ( StringUtils.isNotEmpty( entity.getModId() ) )
{
Modification modification = new DefaultModification(
ModificationOperation.REPLACE_ATTRIBUTE,
GlobalIds.FT_MODIFIER_ID, entity.getModId() );
mods.add( modification );
}
}
}
But this is all really complex right? So to simplify these searches for the
end user we have the auditmgr funcs:
public interface AuditMgr extends Manageable
{
/**
* This method returns a list of admin operations events for a particular
entity
* {@link org.apache.directory.fortress.core.model.UserAudit#dn},
* object {@link UserAudit#objName} and timestamp {@link
org.apache.directory.fortress.core.model.UserAudit#beginDate}.
* If the internal userId {@link
org.apache.directory.fortress.core.model.UserAudit#internalUserId} is set it
will limit
* search by that field.
* <h3></h3>
* <h4>optional parameters</h4>
* <ul>
* <li>
* {@link UserAudit#dn} - contains the LDAP distinguished name for the
updated object. For example if caller
* wants to find out what changes were made to John Doe's user object
this would be
* 'uid=jdoe,ou=People,dc=example,dc=com'
* </li>
* <li>
* {@link UserAudit#objName} - contains the object (authorization
resource) name corresponding to the event. For
* example if caller wants to return events where User object was
modified, this would be 'updateUser'
* </li>
* <li
* >{@link
org.apache.directory.fortress.core.model.UserAudit#internalUserId} - maps to
the internalUserId of user
* who changed the record in LDAP. This maps to {@link
org.apache.directory.fortress.core.model.User#internalId}.
* </li>
* <li>{@link UserAudit#beginDate} - contains the date in which to begin
search</li>
* <li>{@link UserAudit#endDate} - contains the date in which to end
search</li>
* </ul>
*
* @param uAudit This entity is instantiated and populated before
invocation.
* @return a List of objects of type Mod. Each Mod object in list
corresponds to one update or delete event on directory.
* @throws SecurityException
* if a runtime system error occurs.
*/
List<Mod> searchAdminMods( UserAudit uAudit )
throws SecurityException;
Thanks,
Shawn
> On Nov 21, 2016, at 8:39 AM, Chris Pike <[email protected]> wrote:
>
> Looking at the OpenLdap Audit logs. In our setup, it looks like the
> reqAuthzId will always be the same user used to connect to the server, is
> there a way to log the user set in the admin session on the manager?
