Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Portal authentification against AD password

Former Member
0 Kudos

Hello, I am working on a scenario for our HR portal, where the users should authentificate themselves against Active Directory password.

We use the UME datasource on ABAP side and we want to preserve it. The usernames on ABAP back-end are identical to the ADs one. I have already set-up a working SSO scenario via SPNEGO login module, however this solution has been rejected due to the security reasons when used on shared computers. I've got a request where the users need to re-enter their AD password (or username/password) on the portal login screen when trying to connect to the portal.

What I have already investigated, this should be possible with krb5LoginModule. However, I have not found any detailed documentation on how to set-up or troubleshoot this scenario.

I have came to the situation where I do have a working connection to AD server, when looking at the trace, I see this error:

Couldn't find user by attribute uniquename = HTTP/portaldev.bel.com(at)BEL.COM

where the HTTP/portaldev.bel.com(at)BEL.COM is the principal of the portal server account in the AD. I assume that there should be the desired username like MPAT520(at)BEL.COM, not the portal server's principal.

The configuration of krb5LoginModule is as follows:

2. com.sun.security.auth.module.Krb5LoginModule SUFFICIENT ok true true

#1 debug = true

#2 doNotPrompt = false

#3 keyTab = /etc/krb5.keytab

#4 principal = HTTP/portaldev.bel.com(at)BEL.COM

#5 refreshKrb5Config = true

#6 storeKey = true

#7 useKeyTab = true

#8 useTicketCache = true

Could you give me a hint on some good guide or documnetation, or post me some advise how to continue?

Thanks.

3 REPLIES 3

Former Member
0 Kudos

however this solution has been rejected due to the security reasons when used on shared computers

I will spare Tim Alsop the effort of answering this...

Take a look in the EcoHub at the SSO solutions which offer adapters (if the terminal PC is secure!) to re-authenticate the user of the application and not use the terminal user ID.

For kiosks and internal network terminals which are publicly accessible this works nicely and I can recommend it to re-use the AD authentication.

As it uses SNC and you can only have one SNC library installed on the server side... you cannot (to my knowledge) use such terminal based adapters s an isolated solution and use krb5 for the rest.

Cheers,

Julius

0 Kudos

however this solution has been rejected due to the security reasons when used on shared computers

>

> I will spare Tim Alsop the effort of answering this...

Thankyou.

As it uses SNC and you can only have one SNC library installed on the server side... you cannot (to my knowledge) use such terminal based adapters s an isolated solution and use krb5 for the rest.

Actually, SNC is only used for SAP GUI authentication on shared workstations. For portal or any other Web enabled application on ABAP or Java stack, SNC is not used, but Kerberos protocol can be used via Negotiate protocol or using a login form.

former_member182254
Active Participant
0 Kudos

Hi,

It is possible to use Krb5LoginModule to authenticate against AD but there two problems with your current setup:

1. The options that you use are not correct. For this type of authentication you do not need a keytab file.

2. The Krb5LoginModule will authenticate the user and put in the Subject a KerberosPrincipal with name MPAT520(at)BEL.COM. The authentication framework will try to find a user with such user id. Most probably the user ids in the UME are just the first part of the KPN - e.g. MPAT520. If user with such user id is not found then the overall authentication will fail because the server won't be able to create a security session. In order to overcome this problem you need an additional login module which to find the correct user id and put it as 'main' principal in the subject.

I made a simple test on a CE 7.2 system and it worked successfully. Here are the steps I have done:

1. Set system properties for realm and KDC (you can use also the approach with krb5.conf file). I have set them at runtime just for the test with the following krb5sysprops.jsp:

<%@ page import="java.util.*"%>
<html>
<body>
<pre><code>
<%
  String realm = request.getParameter("realm");
  String kdc = request.getParameter("kdc");
  if (realm != null && kdc != null) {
    System.setProperty("java.security.krb5.realm", realm);
    System.setProperty("java.security.krb5.kdc", kdc);
  }
  Properties props = System.getProperties();
  Enumeration propsNames = props.propertyNames();
  while (propsNames.hasMoreElements()) {
      String key = (String)propsNames.nextElement();
      String value = props.getProperty(key);
%>[<%=key%>] = [<%=value%>]
<%	  
    }
%>
</code></pre>
</body>
</html>

Copy it to the default web application and invoke it afterwards with https://host:post/krb5sysprops.jsp?realm=<REALM>&kdc=<KDC>. This will work only for test purposes on a single instance / single server node. For productive usage set the parameters using the Config Tool.

2. Protect an application (or Portal) with the following authentication stack:

com.sun.security.auth.module.Krb5LoginModule REQUISITE

#1 debug = true

com.sap.security.core.server.jaas.SPNegoMappingLoginModule REQUISITE

#1 com.sap.spnego.uid.resolution.attr = krb5principalname

Where UME attribute krb5principalname is mapped to physical attribute userprincipalname from AD. The SPNegoMappingLoginModule is doing the mapping from KPN (MPAT520(at)BEL.COM) to user id in UME. It can do this only if an UME user attribute contains the KPN. If this is not sufficient for your use case then you can implement own login module with custom logic for principal mapping.

Regards,

Dimitar

Edited by: Dimitar Mihaylov on Jun 23, 2011 9:16 AM

Edited by: Dimitar Mihaylov on Jun 23, 2011 9:18 AM