Solved

AD Authentication in SAP BI Launch Pad

Posted on 2014-01-29
8
4,403 Views
Last Modified: 2014-01-30
We are trying to set up AD authentication inside our SAP BI Launch Pad.  I have been following the Crystal-2011-AD-Authentication.pdf instructions and they have been very helpful. I've successfully completed the following:
Created a service account in AD with the appropriate permissions and with Kerberos authentication turned on.
Configured the AD Plugin Page in the CMC and successfully mapped the AD groups/aliases
Successfully started the SIA/CMS under the new AD service account
Successfully verified that the new service account and AD logins are working
Created the bscLogin.conf and krb5.ini files and successfully received a kerberos ticket
Enabled the authentication dropdown for BI Launch Pad
Pointed the app server to the bscLogin.conf and krb5ini files
After all that, I do not see any events in the server logs at all relating to user logon attempts and I get the following error when attempting to login to the BI Launch Pad with AD user credentials:
Account Information Not Recognized: Active Directory Authentication failed to log you on. Please contact your system administrator to make sure you are a member of a valid mapped group and try again. If you are not a member of the default domain, enter your user name as UserName@DNS_DomainName, and then try again. (FWM 00006)
This is where I'm stuck and cannot tell what the problem is.
0
Comment
Question by:Jake Pratt
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
8 Comments
 
LVL 100

Expert Comment

by:mlmcc
ID: 39818390
How do you login?
Are you supplying the username and password or are you trying use the WIndows login as a single signon so when you run Launchpad you don't have to provide credentials?

mlmcc
0
 

Author Comment

by:Jake Pratt
ID: 39818404
I'm trying to get to the SSO, but first you need to successfully do a manual login on the Launch Pad with AD credentials.  That is where I'm getting the error.  I put in an AD user and password and select Window AD as the login type.  I get the error from that attempt.
0
 
LVL 26

Expert Comment

by:Kurt Reinhardt
ID: 39818515
There are several reasons this can fail, such as: typos in the names of the two files created, Tomcat being case sensitive (assuming you're using TOMCAT), not having server names all in UPPERCASE in your files, etc...

I would recommend going through each of the steps again.

Also, one problem I've had was in copying and pasting examples of the krb5.ini file.  It would look good, but not work (too many spaces or missing spaces somewhere) until I copied in and modified a file from another working system.  I've attached a sample that I use for my clients.
krb5.ini
0
What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

 

Author Comment

by:Jake Pratt
ID: 39818590
I had the same thoughts and I have already gone back through the steps again several times. I am confident that I have no typos or other such errors.  My krb5.ini looks just like your sample.  Further, since I have already successfully received a kerberos ticket, I think I can say with confidence that my krb5.ini file is good and working properly. Therefore the problem seems to be somewhere else.
0
 
LVL 26

Accepted Solution

by:
Kurt Reinhardt earned 500 total points
ID: 39818655
With the exception of the one time I had issues with 2008 R1 needing to be patched, any problems I've had have always come down to something simple that I overlooked.  As I mentioned, there are a lot of possible points of failure.  Examples are:

1)  Typos - maybe in the SPN?  One time I goofed and needed to delete and recreate the SPNs.  This didn't stop me from creating tickets, but did prevent SSO from working.

2)  The AD account - did you use the same AD account for the SPNs as you did in the CCM and in the CMC AD Authentication tab?

3)  Did you remember to do the three minimum SPNs required for SSO? There are general, hostname and FQDN SPNs required

4)  Windows AD account - on my last engagement, I had to rely upon the client's AD administrator to create and configure the service account for me and I gave them explicit instructions on what was required.  After spending hours troubleshooting the steps and not getting it to work (just like you), I discovered they never set up trust delegation (page 7).

5)  Act as part of the operating system local policy for the AD Service account- even though I'd asked an AD administrator to do this, I found I had to do it myself (thankfully I had admin rights to the machine in question)

6)  The AD service account explicitly being in the Root of the Administrators group on the Windows Server, not in directory/subdirectory within the Administrators group

7)  On page 11 did you successfully login to Enterprise via AD using a thick client tool?  What tool?  The client tools aren't part of the base installation, so you'd have to download and install them separately if you haven't already.  I tend to test logins through the Business View Manager or the WebI Rich Client.  If you haven't done this, you need to.  Please note, it may still work and fail later in the process, but if it fails here you know you have an issue.

8)  Exact case for the bscLogin.conf and krb5.ini files

9)  The right domain server name in the krb5.ini files (sometimes people put the Enterprise server name in, not the DC)

10)  Incorrect, wrong case or different SPN name in the Windows AD Authentication tab in the CMC.  Is it host name in one place and FQDN in another?


It is always possible there's an issue with one of the various servers involved (needing a patch, having multiple NICS, etc...), but the most often it's something simple that got overlooked (p.s. setting up SSO was so much easier with IIS in previous versions - it only took a few minutes).
0
 

Author Comment

by:Jake Pratt
ID: 39819766
1)  When I run "setspn -L serviceaccount", where serviceaccount is the AD account name for my service account,  I get the following result:
Registered ServicePrincipalNames for CN=SAP Service Account,CN=Users,DC=mydomain,DC=com:
        HTTP/myhost.mydomain.com
        HTTP/myhost
        BICMS/serviceaccount.mydomain.com
Where "myhost" = the host name of my app server, "mydomain" = the name of my domain.

Can you see anything off here?  It all looks good to me.

2)  Yes, I used the same AD account for SPN's, CCM, and the CMC AD authentication tab.

3)  See #1 above.

4)  We're using Server 2008 R2 and it doesn't show delegation quite like the documentation on pg. 7.  There is no delegation tab.  Rather, there is a checkbox under the account tab which is checked, called "Account is trusted for delegation".

5) This is handled by group policy, so we updated the gp to allow "serviceaccount" to act as part of the os.  After gpupdate on the app server, the local policy does indeed show the change.

6)  MYDOMAIN\serviceaccount is specifically on the root of the local Administrators Group on the app server.

7)  Haven't tested with a thick client yet. Where are the install files for either Web Intelligence Rich Client or Business View Manager?

8)  Exact case looks right I think:
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_kdc = true
dns_lookup_realm = true
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac
udp_preference_limit = 1
[realms]
MYDOMAIN.COM = {
kdc = MYDCHOST.MYDOMAIN.COM
default_domain = MYDOMAIN.COM
}

9)  See #8 above

10)  The SPN in the CMC AD setup matches the case shown in #1 above (BICMS/serviceaccount.mydomain.com). Not sure what you are asking about the host name and FQDN in different places.  Are you talking about some setup in the CMC?
0
 

Author Comment

by:Jake Pratt
ID: 39822104
You were right.  It was something simple (like always).  In CMC>Authentication>Windows Active Directory>AD Configuration Summary, the Default AD Domain had to be in all caps. Sheesh!  Thanks for your help.
0
 
LVL 26

Expert Comment

by:Kurt Reinhardt
ID: 39822285
Glad you got it working!
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article demonstrates probably the easiest way to configure domain-wide tier isolation within Active Directory. If you do not know tier isolation read https://technet.microsoft.com/en-us/windows-server-docs/security/securing-privileged-access/s…
Recently, Microsoft released a best-practice guide for securing Active Directory. It's a whopping 300+ pages long. Those of us tasked with securing our company’s databases and systems would, ideally, have time to devote to learning the ins and outs…
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.

738 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question