Skip to Content

Error while trying to map windows AD group

Just to give some background :

We are building a new BO server in Microsoft Azure. BO server is in domain.

We have created service account in domain. There is a one way trust between and domain (abc is trusting domain while xyz is trusted domain).

We have ad groups created in child domains of like, and so on.

From the BO server we can ping and nslookup and the child domains. We are able to locally add the AD groups. We have created SPN and configured Authentication page in CMC as per whitepaper and KBAs. We have kept the default domain in CMC as While trying to add group from, we get an error :

The secWinAD plugin failed to look up the account for the group "\FGG-Global-ZZ-ADGROUP-GS". Please enter non-local groups as DomainName\GroupName and local groups as \\ServerName\GroupName.

In CMS trace, we see In CMS logs, we see : WINAD: ADNetworkBinding::GetDomainController() -- Could not locate a DC for domain child1 or domain does not exist.

If we try to add group from (parent domain), we can add the group.

Could you please let me know what we are missing ?

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Mar 06, 2018 at 11:04 AM

    Hi Shiva,

    I have read the KBAs ; however, my question is the BO server and user/group are in different domain. If the group is in parent domain, it works ; however, gives an error while trying to map group from child domain although parent and child have transitive trust.



    Add comment
    10|10000 characters needed characters exceeded

  • Mar 05, 2018 at 06:46 PM

    (Edited) Can you check if this is relevent to this sap kbases

    Best practices for multi forest configuration:

    1323391 - What are the Microsoft requirements to perform kerberos SSO in multiple AD forests environments with BI and

    1886178 - Intermittent failures with AD groups in remote forest in BI 4.x

    Add comment
    10|10000 characters needed characters exceeded

  • Mar 07, 2018 at 07:17 PM

    If you are attempting to have BI work with multiple AD forests then the 2 way trust is a mandatory requirement (referenced by Shiva)

    In some cases if you have just parent level forests you may be able to bypass this requirement for some tasks such as group mapping, but you would find other tasks (like SSO) will fail in all cases without a forest trust.

    The intermittent failures KBA 1886178 does not apply here because that issue occurs even when the 2 way trust is present due to a DNS issue. If the two way forest trust does not exist then we would expect child domain discovery to fail.

    The BI product can be installed inside a Microsoft environment but that environment must be setup to communicate properly or the Microsoft API's called by BI will fail. If you want to circumvent the Microsoft security then your best bet would be to consult Microsoft as SAP is not going to be able to do this.


    Add comment
    10|10000 characters needed characters exceeded

    • In the direction of group mapping BI uses Microsoft API's that use LDAP queries and DNS to discover domains. Without a trust those API's will fail (as you saw) but you can circumvent this by manually adding DNS info maybe hosts file, etc. The problem is you are setting yourself up to us a configuration that is not tested, and down the road you could run into issues where some communication will not occur no matter what DNS info you try to add... So it's just much safer to use the forest trust instead.

      Now on the client direction the users will negotiate via kerberos which must have a forest trust so that the SPN requests in the other forest are found. Since you do have a trust in this direction SSO could work. There are more rules to it than just the trust 1st get SSO working in the local forest, and then verify the client in the remote forest are following the rules in such as using the FQDN and verifying that the BI domain (http://*bidomain) is in the browser local intranet.

      Other issues to watch out for are the browser (IE 11 on win 10 for instance can only perform SSO via constrained delegation) We do not know if this config will work in multiple forest with 2 way forest trust. IE 11 credential guard would need to be removed but this issue would also occur in the local forest

      Chrome has the same issue but can be bypassed by adding the URLS in the registry. that is all mentioned in the multiple forest KBA