bshefflette Absent Member.
Absent Member.
695 views

Helpdesk Profile Match

I am trying to configure a Helpdesk Profile.
In the current schema, we have a list of DN's on an attribute inside of each department which acts as a master record of the Helpdesk Admins for that department.

ou=ABC,ou=Facilities,o=Company
ou=DEF,ou=Facilities,o=Company
ou=XYZ,ou=Faciltiies,o=Company

Inside ABC (and all other facilities) there is an attribute "staffHelpdesk"
staffHelpdesk is a multivalued DN list of users (the master record of helpdesk admins for each department).

In my Helpdesk Profile Match, I need to be able to search that attribute in all of the facilities to see if the user's DN is listed, if it is, he will be an authorized helpdesk user for that facility. My original intent was to do a profile search filter of "staffHelpDesk=@LDAP:DN@", this errors in ERROR, ldap.LdapPermissionTester, error reading matching users: 5015 ERROR_UNKNOWN (unexpected error during ldap search (profile=default), error: 5015 ERROR_UNKNOWN (ldap error during searchID=131, error=javax.naming.InvalidNameException: o=Company: [LDAP: error code 34 - Invalid DN Syntax]))


My questions are:
Can you use macros for dynamic searching to match profiles?
Can you use macros in any of the searching filters for Helpdesk?
Is there another way to accomplish this without redesigning our schema and processes?
0 Likes
1 Reply
Anonymous_User Absent Member.
Absent Member.

Re: Helpdesk Profile Match

Hello,

This is an enhancement that i registered in the RMS portal two years ago,
https://secure-www.novell.com/rms/rmsTool?action=WwwActions.viewPropsPage&reqId=105650, and in the new Ideas portal:
https://ideas.microfocus.com/MFI/identity-manager/Idea/Detail/13048

"Decentralized administration (as an example manager performing tasks on the own staff) can only be done by creating new
profiles for every manager or by setting individual or group acl's for every new manager.

Existing relationships already defined by attributes can't be used.

A very easy solution would be to add macro support (like the one used in email templates) to LDAP filters:
With the use of macros different modules (like Helpdesk) could easily be used for decentralized administration to dynamic scopes
with any configuration changes in SSPR.

As an example, the following filter in the Helpdesk module would allow a manager to do tasks on the own staff but no one else:
(&(objectClass=inetOrgPerson)(directReports=@LDAP:DN@)(|...))"

I thought this would be an easy enhancement since the macro parsing is already in place but not used with LDAP filters but
obviously I'm wrong...

Best regards,
Tobias

On 2017-10-06 22:54, bshefflette wrote:
>
> I am trying to configure a Helpdesk Profile.
> In the current schema, we have a list of DN's on an attribute inside of
> each department which acts as a master record of the Helpdesk Admins for
> that department.
>
> ou=ABC,ou=Facilities,o=Company
> ou=DEF,ou=Facilities,o=Company
> ou=XYZ,ou=Faciltiies,o=Company
>
> Inside ABC (and all other facilities) there is an attribute
> "staffHelpdesk"
> staffHelpdesk is a multivalued DN list of users (the master record of
> helpdesk admins for each department).
>
> In my Helpdesk Profile Match, I need to be able to search that attribute
> in all of the facilities to see if the user's DN is listed, if it is, he
> will be an authorized helpdesk user for that facility. My original
> intent was to do a profile search filter of "staffHelpDesk=@LDAP:DN@",
> this errors in -ERROR, ldap.LdapPermissionTester, error reading matching
> users: 5015 ERROR_UNKNOWN (unexpected error during ldap search
> (profile=default), error: 5015 ERROR_UNKNOWN (ldap error during
> searchID=131, error=javax.naming.InvalidNameException: o=Company: [LDAP:
> error code 34 - Invalid DN Syntax]))-
>
>
> My questions are:
> Can you use macros for dynamic searching to match profiles?
> Can you use macros in any of the searching filters for Helpdesk?
> Is there another way to accomplish this without redesigning our schema
> and processes?
>
>


0 Likes
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.