Kerberos Authentication User Resolution Example issues and suggested solutions

Transcription

1 Kerberos Authenticion User Resolution Example issues and suggested solutions Prick Whitty SAP Product Support

2 This document is intended to provide informion about UME User and Account tributes and how they are mapped to LDAP tributes when an LDAP directory is used as the UME dasource. It suggests an approach to choosing the correct user mapping mode and source when there is no tribute displayed in the user administrion UI with a value th can be used to resolve the user from their Kerberos Principal Name (KPN). Finally it provides some examples of user resolution issues and suggests possible solutions. Note: As with KBA Troubleshooting kerberos authenticion user resolution issues, this document is only relevant for cases where the UME uses an LDAP directory as its dasource and not DB-only or ABAP dasources. LOGICAL ATTRIBUTES AND ATTRIBUTE MAPPINGS For each user in the UME there is an associed User principal and Account principal, each with its own set of logical tributes. For more informion refer to the help documention: Logical Attributes. As described in the guide tached to note New SPNego Implemention, the AS Java s SPNego implemention User Mapping modes and sources allow you to choose whether User tributes (firstname, lastname etc.) or Account tributes (logon id, logonalias, principal, realm) are used to resolve the user from the KPN extracted from the received Kerberos ticket. In the case where the UME is using an LDAP dasource, some User and Account logical tributes are mapped to tributes from the LDAP directory. These mappings are maintained in the dasource configurion file th the UME uses for interfacing with the LDAP directory. User tribute mappings For each LDAP dasource defined in the dasource configurion file, there is a section where User logical tributes are mapped to tributes nive to the underlying LDAP directory. For example, in a SAP delivered MS AD specific dasource configurion file, some of the User tribute mappings look as follows: <principal type="user"> <namespace name="com.sap.security.core.usermanagement"> <tribute name="firstname"> <physicalattribute name="givenname"/> <tribute name="displayname"> <physicalattribute name="displayname"/> <tribute name="lastname"> <physicalattribute name="sn"/> <tribute name="fax"> <physicalattribute name="facsimiletelephonenumber"/> <tribute name="uniquename"> 2

3 Account tribute mappings For each LDAP dasource defined in the dasource configurion file, there is a section where Account logical tributes are mapped to tributes nive to the underlying LDAP directory. For example, in a SAP delivered MS AD specific dasource configurion file, some of the Account tribute mappings look as follows: <principal type="account"> <namespace name="com.sap.security.core.usermanagement"> <! j_user is the logon id -> <tribute name="j_user"> <tribute name="logonalias"> <tribute name="j_password"> <physicalattribute name="unicodepwd"/> <tribute name="userid"> </namespace> <namespace name="com.sap.security.core.authenticion"> <tribute name="principal"> <tribute name="realm"> <tribute name="domain"> </namespace> </principal> Note th in the account tribute mapping section, the principal, realm and domain tributes are in the com.sap.security.core.authenticion namespace. CHOOSING A MAPPING MODE AND SOURCE Refer to the SPNego Configurion Guide tached to note New SPNego Implemention and the SAP Help documention Changing User Mapping for Kerberos for informion on the possible User Mapping modes and some examples. Normally, to choose an approprie mapping, you simply display users in the User Administrion UI and check which tribute value mches the users KPNs or the prefix part of the KPNs and then choose th as the source for the User Mapping mode. However in certain cases it can occur than there is no tribute displayed in the User Administrion UI th can be used for user resolution. For example, previous customizion of the dasource configurion file may mean th the logon id does not mch the prefix part of the KPN for example. When you are certain th there is no User or Account tribute displayed in the User Administrion UI whose value mches the KPN or KPN prefix, then one approach is to examine the user tributes in the LDAP directory and proceed from there. The following are some considerions when choosing an approprie user mapping mode and source: 3

4 LDAP tributes Review the tributes of the user in the LDAP directory using nive tools or an LDIF export Is there an LDAP tribute whose value mches the KPN received or just the principal part of the KPN received? If not, can the value of an LDAP tribute be changed within the LDAP directory to mch the KPN received or the principal part of the KPN received? Can a new LDAP directory tribute be creed and populed with a value th can be used to mch a user to the KPN? Dasource configurion file If you ve established th there is a suitable LDAP tribute and value, examine the dasource configurion file th the UME is configured to use If there is an LDAP tribute whose value mches the KPN received or the principal part of the KPN received, is the tribute mapped to any UME Account tribute or User tribute in the XML? If there is no suitable tribute mapping in the dasource configurion file, can a User tribute or Account tribute (j_user, logonalias, principal) mapping be changed so th it is mapped to the LDAP tribute whose value mches the KPN received or the principal part of the KPN received? Customizion of dasource configurion files including changing tribute mappings is supported, however it should only be done as a last resort. From the perspective of the configurion of User Mapping for Kerberos authenticion, tribute mappings should only be changed when it is certain th all combinions of User Mapping modes and sources do not work with the existing tribute mappings in the dasource configurion file. Before changing any tribute mapping in the dasource configurion file, you should check if the tribute has been explicitly configured for use in other authenticion scenarios, for example in BasicPasswordLoginModule and ClientCertLoginModule, see User Mappings in the Authenticion Framework of SAP NetWeaver Applicion Server (AS) Java. If there is no suitable tribute mapping in the dasource configurion file, can any of the User tribute mappings be changed to use the LDAP tribute? If there is no User tribute mapping th can be changed, can the principal Account mapping be changed? Usually the tribute mapping for the principal tribute can be changed without unexpected side effects since the tribute is intended for the exact purpose of user resolution. If there is some LDAP tribute whose value mches the prefix part of the KPN, but it is not mapped to any logical tribute in the dasource configurion file, mapping the principal tribute to th LDAP tribute in the dasource configurion file should allow successful user resolution. With this mapping in place Mode principal and REALM, Source: ADS Da Source can be used. Important: If the value of the ume property ume.ldap.access.multidomain.enabled is false, then the REALM is not considered during user resolution however, if it has value true, the REALM will be checked and note Multi-Domain Logon Using Microsoft Active Directory should be applied so th the UME correctly reads the REALM. The j_user Account tribute mapping also warrants mentioning since by default, the j_user tribute stores the logon ids th users use when logging on to applicions using logon id and password. When the UME is configured to use an LDAP directory dasource, the j_user tribute mapping determines which LDAP tribute 4

5 value is used as logon id. So you must be aware th any change to the j_user tribute mapping for Kerberos user resolution purposes will usually also impact authenticion via logon id and password. When the UME is using an LDAP dasource (the case for which this document was written), the logonalias tribute mapping can be changed without impacting how users log on to the AS Java using logon id and password, unless LogonAlias has been explicitly configured for use in other authenticion scenarios, for example in BasicPasswordLoginModule and ClientCertLoginModule, see User Mappings in the Authenticion Framework of SAP NetWeaver Applicion Server (AS) Java. Usually, in order to change the LDAP tribute used by users when logging on to the AS Java using logon id and password, changing the j_user tribute mapping suffices and no change to the logonalias tribute mapping is required. Being aware of this can often make it feasible to change the logonalias tribute mapping for Kerberos authenticion user resolution purposes. SPNego wizard If you ve established th there is a suitable LDAP tribute and th it is mapped to a User or Account logical tribute in the dasource configurion file, choose the approprie mapping in the SPNego wizard Is the LDAP tribute whose value mches the KPN received or the principal part of the KPN received, mapped to a User (source: User tribute) or an Account (logon id (j_user), logonalias, principal) tribute? Does the LDAP tribute value mch the entire KPN (Principal@REALM) or only the principal part of the KPN (Principal AND REALM/Principal Only) Example flow chart There is a flow chart tached to KBA Troubleshooting kerberos authenticion user resolution issues which illustres the process of choosing an approprie mapping mode and gives some examples of tribute mappings th could possibly be changed if you are certain th none of the User Mapping mode and source combinions will work with the existing tribute mappings. Note th the flow chart was written only for the case where an LDAP tribute value mches the principal part of the KPN, and not the entire KPN. Additionally it does not suggest any changes to the j_user tribute due to the aforementioned impact on logon ids but such a change is possible if the resulting change to logon ids is acceptable to you. 5

6 EXAMPLE ISSUES For each example issue th follows, traces showing the KPN extracted from the Kerberos token, the mapping mode and source used and the exception th occurred when user resolution failed are provided. Even if the exception th occurs with the issue th you are facing is not present in this document, referring to the suggested solutions here may still prove helpful. Example1 KPN and mapping mode from traces KPN extracted from encrypted ticket: [SPNEGOUserMapping: mode = principal, source = logonid] converted to user mapping filter [[logonid],_]. User mapping filter to be used for resolving local user: [logonid],_ User mapping filter [[logonid],_] will be used to map KPN [johndoe@saprealm.com] to a local user. Exception when user resolution fails No user with logon id = johndoe found Could not valide SPNEGO token. [EXCEPTION] com.sap.engine.services.security.authenticion.umapping.usermappingnosuchuserexception: USER_AUTH_FAILED: User account for logonid "johndoe" not found! com.sap.engine.services.security.authenticion.umapping.usermappingserviceimpl.getuserbylogonid (UserMappingServiceImpl.java:58) com.sap.security.core.server.jaas.spnego.util.spnegousermappingutil.searchuser(spnegousermapping Util.java:59) com.sap.security.core.server.jaas.spnegologinmodule.processauthorizionheader(spnegologinmodule.java:531) com.sap.security.core.server.jaas.spnegologinmodule.login(spnegologinmodule.java:157) com.sap.engine.services.security.authenticion.umapping.usermappingserviceimpl.getuserbylogonid (UserMappingServiceImpl.java:51) more Caused by: com.sap.security.core.persistence.dasource.persistenceexception: User account for logonid "johndoe" not found! Attribute Mapping <tribute name="j_user"> <physicalattribute name="companysapid" /> <tribute name="logonalias"> <physicalattribute name="companysapid" /> <namespace name="com.sap.security.core.authenticion"> <tribute name="principal"> <physicalattribute name="companysapid" /> 6

7 Cause The KPN is The mapping used is Mode: principal only, Source logonid (j_user) which means th the UME searches for a user whose logon id mches the prefix part of the KPN, in this case johndoe. Because j_user is mapped to companysapid, the LDAP directory is searched for user whose companysid=johndoe, but no such user is found. In this case the j_user tribute mapping had previously been changed from samaccountname to companysapid so th users could use the companysid tribute value as logon id when logging on to the AS Java. Changing the tribute mapping for j_user alone is sufficient to achieve this; however the tribute mappings for logonalias and principal were also changed from samaccountname to companysapid. This was not required. Since the user s samaccountname value in the Active Directory was johndoe, if these erroneous changes were not made either the j_user or the principal account tributes could possibly have been used for user resolution Possible solutions Check if there is some other user tribute mapped to samaccountname and if there is, use th in Mode: principal only, Source: user tribute. Change the tribute mapping for one of the User tributes so th the User tribute is mapped to the relevant LDAP tribute samaccountname and use Mode: principal only, Source: user tribute Change the tribute mapping for logical tribute logonalias back to the default samaccountname and choose Mode: principal only, Source: logon alias. Change the tribute mapping for the principal tribute back to the default samaccountname and choose Mode: Principal and REALM, Source: ADS Da Source keeping in mind the value of ume.ldap.access.multidomain.enabled as mentioned in Choosing a Mapping Mode and Source above. Example2 KPN and mapping mode from traces KPN extracted from encrypted ticket: john_doe@saprealm.com [SPNEGOUserMapping: mode = principal, source = tribute, tributename = principal, tributenamespace = com.sap.security.core.authenticion] converted to user mapping filter [com.sap.security.core.authenticion:principal,_]. User mapping filter to be used for resolving local user: com.sap.security.core.authenticion:principal,_ User mapping filter [com.sap.security.core.authenticion:principal,_] will be used to map KPN [john_doe@saprealm.com] to a local user. SPNEGOUserMapping case: {namespace:}tr,_ Search tribute: [namespace=com.sap.security.core.authenticion, name=principal, value= john_doe, iscasesensitive=false] Entering method with ([namespace=com.sap.security.core.authenticion, name=principal, value= john_doe, iscasesensitive=false]) 7

8 Found 0 users according to search criteria. Exception when user resolution fails Could not valide SPNEGO token. [EXCEPTION] com.sap.engine.services.security.authenticion.umapping.usermappingnosuchuserexception: No user with user tributes [[namespace=com.sap.security.core.authenticion, name=principal, value=john_doe, iscasesensitive=false]] found com.sap.engine.services.security.authenticion.umapping.usermappingserviceimpl.getuserbyuseratt ributes(usermappingserviceimpl.java:115) com.sap.security.core.server.jaas.spnego.util.spnegousermappingutil.searchuser(spnegousermapping Util.java:106) com.sap.security.core.server.jaas.spnegologinmodule.processauthorizionheader(spnegologinmodule.java:541) com.sap.security.core.server.jaas.spnegologinmodule.login(spnegologinmodule.java:154) Attribute Mapping Cause <tributemapping> <principal type="account"> <namespace name="com.sap.security.core.usermanagement"> <tribute name="j_user"> <tribute name="logonalias"> <tribute name="j_password"> <physicalattribute name="unicodepwd"/> <tribute name="userid"> </namespace> <namespace name="com.sap.security.core.authenticion"> <tribute name="principal"> <tribute name="realm"> The KPN is john_doe@saprealm.com. The mapping mode used is Mode: principal only, Source: User Attribute. In the LDAP directory the samaccountname tribute has value john_doe, therefore a logical tribute th is mapped to samaccountname can be used for user resolution. Here the tribute chosen for user resolution was principal which as can be seen above is mapped to samaccountname. However, the principal tribute is an Account tribute and not a User tribute, hence an tempt to find a user with a User tribute principal=john_doe fails and a UserMappingNoSuchUserException results. 8

9 Possible solutions Since j_user is mapped to samaccountname, choosing Mode: principal only, Source: logon id could be used for user resolution Since logonalias is mapped to samaccountname, choosing Mode: principal only, Source: logon alias could be used for user resolution Since principal is mapped to samaccountname, Mode: Principal and REALM, Source: ADS Da Source could be used for user resolution, but keep in mind the value of ume.ldap.access.multidomain.enabled as mentioned in Choosing a Mapping Mode and Source above. Example3 KPN and mapping mode from traces User mapping SPNEGOUserMapping: mode = principal@realm, source = logon_alias converted to user mapping filter [[logonalias]] User mapping filter to be used for resolving local user: [logonalias] KPN extracted from encrypted ticket: john_doe@saprealm.com User mapping filter [[logonalias]] will be used to map KPN [john_doe@saprealm.com] to a local user. SPNEGOUserMapping case: [logonalias] Searching for user by logon alias: john_doe@saprealm.com Exception when user resolution fails Could not search for user by logon alias: john_doe@saprealm.com [EXCEPTION] com.sap.security.api.nosuchuseraccountexception: User account for logon alias "john_doe@saprealm.com" not found! com.sap.security.core.imp.useraccountfactory.getreadonlyuseraccountbylogonalias(useraccountfacto ry.java:529) com.sap.security.core.imp.userfactory.getuserbylogonalias(userfactory.java:1255) com.sap.security.spnego.util.spnegousermappingutil.searchuserbylogonalias(spnegousermappingutil. java:155) Attribute Mapping <tributemapping> <principal type="account"> <namespace name="com.sap.security.core.usermanagement"> <tribute name="j_user"> <physicalattribute name="companysapid"/> <tribute name="logonalias"> 9

10 <tribute name="j_password"> <physicalattribute name="unicodepwd"/> <tribute name="userid"> </namespace> <namespace name="com.sap.security.core.authenticion"> <tribute name="principal"> <tribute name="realm"> Cause The KPN is The mapping mode used is Mode: Source: logon alias. In the LDAP directory the samaccountname tribute has value john_doe, therefore a logical tribute th is mapped to samaccountname can be used for user resolution. The default mapping of the j_user tribute has been changed from samaccountname to companysapid in order to allow users enter their companysapid when logging onto the AS Java. The logonalias mapping has correctly been left unchanged, however a mapping mode unsuitable for using the logon alias to resolve the user has been chosen. Mode: principal@realm, Source: logon alias tempts to find a user with logon alias john_doe@saprealm.com i.e. there is a search for a user with samaccountname=john_doe@saprealm.com, which fails to return any user. Possible solutions If there is an LDAP tribute whose value mches john_doe@saprealm.com, Mode: principal@realm, Source: user tribute could be chosen with the relevant LDAP tribute specified as the source. Since it is known th the samaccountname tribute has value john_doe, Mode: principal only, Source: logon alias could be chosen Since it is known th the samaccountname tribute has value john_doe, Mode: Principal and REALM, Source: ADS Da Source could be used for user resolution, but keep in mind the value of ume.ldap.access.multidomain.enabled as mentioned in Choosing a Mapping Mode and Source above. 10

11 SAP AG or an SAP affilie company. All rights reserved. No part of this publicion may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The informion contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Nional product specificions may vary. These merials are provided by SAP AG and its affilied companies ( SAP Group ) for informional purposes only, without represention or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the merials. The only warranties for SAP Group products and services are those th are set forth in the express warranty stements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Please see for additional trademark informion and notices.