Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
skoehler Respected Contributor.
Respected Contributor.

SSPR 4.1 missing Macro for logged in User

Hi there,
here my business case:
Using the SSPR 4.1 helpdesk module I want to track on the LDAP-Object (regular user), who (helpdesk user) did a change to the user (so I can pick it up with IDM later on...)
A side hint, as it may add to the szenario: SSPR runs against a different LDAP Server than IDM driver is running, so eDir Replica Sync and sync delays are involved...

I tried the macro @LDAP:DN@ which seemd obvious to me in the first place, but because I did a search for the regular user before, the macro responds with the regular users DN, not the helpdesk user DN.

I have the configuration "Use Proxy Connection" disabled, as my helpdesk user has the appropriate eDir Rights, so I wanted to relate on modifiersName (thought this is a simple way...), but in the XDS document on the IDM server it said:

<nds dtdversion="4.0" ndsversion="8.x">
<product edition="Standard" version="">DirXML</product>
<contact>Novell, Inc.</contact>
<modify cached-time="20170509090600.950Z" class-name="User" event-id="LS00135P#20170509090600#3#1:76f72dd5-532d-495a-21ac-d52df7762d53" qualified-src-dn="...\OU=Users\OU=PROD\CN=RegularUser" src-dn="...\Users\PROD\RegularUser" src-entry-id="147807" timestamp="1494320756#9">
<modify-attr attr-name="modifiersName">
<value timestamp="1494318905#2" type="string">CN=AdminUser,OU=SSPR,OU=Services,...</value>
<value timestamp="1494320756#9" type="string">CN=SSPRProxy,OU=SSPR,OU=Services,...</value>
<modify-attr attr-name="MyAttribute">
<value timestamp="1494320756#2" type="string">TRUE</value>

That looks like the change was done by the proxy user, not the helpdesk user... So I investigated the LDAP trace further on to verify my SSPR config is doing good and I found the following:

11:29:19 9E2E6700 LDAP: DoModify on connection 0xda25c00 (belonging to Helpdesk User)
11:29:19 9E2E6700 LDAP: modify: dn (cn=RegularUser,ou=PROD,ou=Users,...)
11:29:19 9E2E6700 LDAP: modifications:
11:29:19 9E2E6700 LDAP: replace: MyAttribute
11:29:19 9E2E6700 LDAP: Sending operation result 0:"":"" to connection 0xda25c00

that looks good and the settings works as designed...
further down the trace I found:

11:29:19 9EBA1700 LDAP: DoModify on connection 0xdb4b500 (belonging to the SSPRProxy User)
11:29:19 9EBA1700 LDAP: modify: dn (cn=RegularUser,ou=PROD,ou=Users,...)
11:29:19 9EBA1700 LDAP: modifications:
11:29:19 9EBA1700 LDAP: delete: pwmEventLog
11:29:19 9EBA1700 LDAP: add: pwmEventLog
11:29:19 9EBA1700 LDAP: Sending operation result 0:"":"" to connection 0xdb4b500

That might explain why the XDS document of the IDM server has the incorrect information on the modifiers name, assuming that eDir replica sync sends over the last state of the object...

##### my conclusion: having a macro for the currently logged in User would help me a lot here...
Other ideas also welcome...

Thanks in advance
2 Replies
skoehler Respected Contributor.
Respected Contributor.

Re: SSPR 4.1 missing Macro for logged in User

I just confirmed: when IDM Engine and SSPR are configured to use the same eDir/LDAP Server, modifiers Name is Helpdesk User, not SSPRProxy...

Brings me back to the question: is there any macro I can use to get the logged in user (helpdesk user), not the currently selected user (regular user)?

skoehler Respected Contributor.
Respected Contributor.

Re: SSPR 4.1 missing Macro for logged in User

In the SSPR configuration under "Settings-Auditing-Audit Configuration" I disabled User Audit Event Type "Helpdesk Action". This blocks writing to pwmEventLog (as SSPRProxy) when executing the Helpdesk Action (as Helpdesk User). Now the modifiers Name sticks to the Helpdesk user (even when Splitting SSPR/IDM Processing over 2 servers) and I can process it further on with IDM. That for the price of loosing the audit event...

That solves the issue in my lab where there is no traffic.

Will that be a robust solution for a high-traffic Environment? I hope it is good enough for a user that locked himself out of the System due to forgotten Password...

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.