MSAD Admin Conflicting With Native Admin

This is a pretty common issue we face, when our Native Admin conflicts with  MSAD Admin. A 

simple solution to this is to set Filters to Limit Users. In this case if you move your MSAD first in 

search order and you have an MSAD user named admin then you will be able to create a 

planning application using Admin BUT you wont be able to log in to the application using Admin 

id; Here is the illustration:

Lets assume that we have two admin users, one is default native admin (Which you cant delete, 

at most you can remove all the provisioning) and other one is from our MSAD named dada 

(Dada is the name of a friend of mine whose MSAD server I have used here for configuration, 

Thanks Dada! ), and my MSAD directory dada is rank 1 in the search order and Native is 2nd.

Now if you try to create a planning application using Native Admin then you will get the below 

error: 

And now even if you will try to login as admin you will be the below error: 

If you will look at planning's syserror logs:
"

com.hyperion.planning.InvalidUsernameException: User admin does not exist for this application.
 at com.hyperion.planning.HspJSImpl.login(Unknown Source)
 at com.hyperion.planning.HspJSImpl.login(Unknown Source)
 at com.hyperion.planning.HyperionPlanningBean.Login(Unknown Source)
 at 

com.hyperion.planning.appdeploy.HspManageAppSession.registerAppWithSharedServices(U

nknown Source)

 at com.hyperion.planning.appdeploy.HspManageAppSession.createApplication(Unknown 

Source)
 at HspCreateApp.Handle(Unknown Source)

at HspCreateApp.doPost(Unknown Source)

 at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:821)
 at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
 at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
 at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
 at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:27)
 at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:57)
 at HspValidationFilter.doFilter(Unknown Source)
 at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:57)
 at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:111)
 at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313)
 at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413)
 at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:94)
 at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:161)
 at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
 at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:57)
 at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:136)
 at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:57)
 at 

weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
 at 

weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
 at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
 at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
 at 

weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
 at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
 at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
      at weblogic.work.ExecuteThread.run(ExecuteThread.java:176)" 

And this is right because if we look at our HSP_USER table for this planning application we will 

find that even though we have logged in using Native Admin but the application owner is the 

MSAD admin which is causing all the issue.

In order to solve this problem permanently lets go back to our shared services, take out the 

MSAD admin from all the Native groups, remove all the direct provisioning, if any and lets apply 

a user filter to MSAD to make sure MSAD Admin will no longer be listed in the Shared 

Services under our 'dada' MSAD.

Click on edit and go to second screen of MSAD configuration:

Here is our Magic Filter (!(sAMAccount=Admin)), click on next and finish:

Restart as mentioned.

Before Restart:

After restart if we check our Shared Service MSAD admin is no more listed:

Now lets try creating a new planning app:

If will be will to log in as admin this time, it will work as charm:

Wow! I m in... but what about our broken TestApp4,?? We cant leave it like that, are we able to 

log in to that application now?? 

this is because still USER_ID in HSP_USERS is on MSAD admin, copy the SID details from the repository of newly created application to TestApp4 repository and restart the Planning Services. 

Here we go we can log into TestApp4 Now! 

To have more details on MSAD configuration and filters you may have a look at below links:

http://download.oracle.com/docs/cd/E17236_01/epm.1112/hss_admin/ch03s05.html

Using User Filter to Reduce the Number of Users Retreived from Microsoft Active Directory 

(MSAD) (Doc ID 1227144.1)

Cheers..!!!

Rahul Sharma