cancel
Showing results for 
Search instead for 
Did you mean: 

SSO Business Objects Infoview not working from other domain

Former Member
0 Kudos

Hello,
We use Business Objects XI3 SP5. Our users and the BO server are in Domain A. They log in to Infoview with SSO. That works fine.
Now we want to migrate our users to Domain B. There is a full two-way trust between the two domains.
To accomplish that we added a AD group from Domain B in CMC under Authentication -> Windows AD.
Furthermore we modified the krb5.ini.


When a user now log in to Domain B en open the link to Infoview we see that single-sign-on tries to login the user, but gets the error that the user is not authorisied to use the application.
We checked that the new AD group has the proper right within BO ( CMC -> Applications).
I can see that the user that tried to log in is created within BO.
We used kinit to verify that kerberos works fine from a Domain B account.


When I manual tries to login I get an error that says the Active Directory Groups for the account cannot be retrieved. The same error I gets when I try to logon with the Desktop Intelligence tool on the server.

Since 1,5 year we see an error in the CMS trace log that says:
assert failure: (.\ADQueryEngine.cpp:375). (0 : WINAD: ADQueryEngine::Query() -- No short name!).
This log grows very fast with this error every day (20 MB in haf an hour).


I do’nt now if this has a realtion with our probleem.

We are now out of options. I hope someone can help us.

Regards,
Oscar

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member189884
Contributor
0 Kudos

I'd suggest looking to set the usefqdnfordirectoryservers registry key if you have not already done so.

KBA 1199995

Former Member
0 Kudos

Hello Josh,

The key you mention has already been set in the registry of the server and did not resolve the problem.

Thanks,

Oscar


former_member926196
Active Participant
0 Kudos

Hi Oscar,

Can you make sure that the users coming from the secondary domain are able to login into Business Object with username@DOMAIN.COM

Also try adding the Infoview URL to the trusted sites of the browser.

-Ambarish-

Former Member
0 Kudos

Hello Ambarish,

When logging on (AD auth) in Infoview (no SSO) we do get a Kerberos ticket. in Infoview we get the error below:

Account Information Not Recognized: The Active Directory Authentication plugin could not authenticate at this time. Please try again. If the problem persists, please contact your technical support department. (FWM 00005).

The URL is in the trusted sites.

Oscar

former_member189884
Contributor
0 Kudos

Do the users or groups currently exist in BOTH domain a and b?

former_member926196
Active Participant
0 Kudos

Hi Oscar,

What is the service principal name in the CMC set to??

If its BOCMS/service_account.domain.com, then replace it with service_account@DOMAIN.COM and update the setting to see if it helps !

-Ambarish-

Former Member
0 Kudos

Yes, they exist in both domains at the moment as we are in the process of migrating from the old domain to the new. As a test we have a test group from the new domain, so the group is a different one in both domains.

Update:

Tests with an account ONLY available in the new domain have been done with the same result.

Former Member
0 Kudos

Will test this tonight after business hours (in about 5 hours) and post the result tomorrow.

Former Member
0 Kudos

We tested this yesterdayevening. The reult was that SSO from domain A was still working but it appeared that SSO from domain B was not even tried. Attempting a manual logon resulted in the same error we had before.

former_member189884
Contributor
0 Kudos

I think it's time you open an incident with support, cms logs and a thorough review would be the next suggestions as it seems you've tried some basics.

The trust you mention is a two-way is it external?

Former Member
0 Kudos

Forest A contains a root domain (emtpy, single label) and a child domain. Forest B only contains one domain. There used to be only a forest trust between the root domain in forest A and the forest B domain. Because of VMware products that were not able to do authentication for the child domain in forest A a shortcut / external trust was created between the child domain and the forest B domain.

Will take a look at the support incident option.