iLO - Cross Forest Nesting.

[thirusrinivasan]

Goal is to manage the iLO from our Support Forest using support forest credentials. Testing this in our lab we are running into a issue.

iLO HP Target object and the HP roles are created in Forest A.

Added the HP roles to the HP target object.

Added users from Forest A as member of the HP roles.

Forest A has a trust to Forest B. Added user from Forest B to the role in Forest A.

Login to iLO works for the user in Forest A and not working for Forest B user.

Why is this not working when the user account from Forest B is a member of a HP role in Forest A ? What are we missing here ?

Your thoughts are much appreciated.

Shiva

[Chris Davenport]

I see you haven't gotten any replies. That's surprising and unfortunate. I'm not sure if your issue has been addressed yet, but if not, perhaps this will help.

iLO has a straightforward method of authentication, one that you can easily test using LDP or another standalone LDAP browser utility. Disable following of referrals and use only SIMPLE authentication over SSL to properly emulate the iLO's behavior.

In this instance, iLO should be configured with the IP Address/name of a server/domain in Forest A.

iLO will try first to pass the credentials typed verbatim, so to circumvent an issue with username lookups, use the fully qualified LDAP DN of the Forest B user, at least until the problem is understood. I believe iLO may have an issue with using the UPN (username@domain) form of the username in these situations.

Once the ldap connection is authenticated, iLO will read the configured iLO object, using a simple base object search. Test this using the LDP tool (or similar), be sure to use the Forest B user's credentials the same way the iLO does, and make note of the hpRoleMembership attribute values.

If that succeeds, the iLO will use the returned hpRoleMembership attribute's values to determine the assigned rights. It successively reads each role, building the list of rights from them. Use the LDP tool to do the same, search for each role and ensure the user can read them and make note of the obtained rights.

The user must have obtained the LOGIN right for the session to continue.

I suspect you've run into either an authentication issue, where the form of the username is disallowed, or a directory server issue where the user's credentials aren't accepted by the directory server or, once accepted, the user's rights to the role object are not applied correctly.

If, in your testing, the forest B user does not have the ability to read the role after authenticating, you may need to manually grant the user the ability to read the role. That would mean the self-read rights ordinarily granted by role membership weren't granted to the user from another forest.

[ccpyle]

Chris, thanks for informing me of this thread on my previous thread ( http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1112294 )

I did all the steps you listed using LDP.exe and I think the blockade is caused by the referral of the cross-domain or cross-forest user object existing as a SID in CN=ForeignSecurityPrincipals. My only guess is that because of this, the authentication fails due to a reliance of a referrer perhaps...I don't know...I am not an LDAP expert by any means.

I do know that in my venture to get this working over a year ago, I finally got a hold of someone in HP technical support who finally flat out told me, "No, cross domain functionality does not work". We ended up creating a few generic IDs for our business units to use for iLO authentication in the same domain.

I really wish that there was a technique to make this work. It would be one less password and ID for my users to remember.

[Chris Davenport]

iLO doesn't have the ability to chase referrals, which does cause much of the problem with cross domain or cross forest authentication.

We've recommended using AD/AM or another metadirectory service as a possible workaround in the past. They can be a fair hassle to set up and maintain, however.

Another option is to configure iLO to use the global catalog, port 3269 is the LDAP SSL port for it, I believe.

I can't say offhand if that will solve your problem, because we're outside support territory and it's been a few years since I tested that, but if you can get LDP to pass those tests, iLO will work.