| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to Setup Kerberos Authentication for Soap Services ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| rama91 |
 Posted: Wed Sep 18, 2019 8:23 am Post subject: How to Setup Kerberos Authentication for Soap Services ? |
 |
|
Novice
Joined: 28 Aug 2019
Posts: 15
|
Hi,
We have IIB 10.0.0.12 running on a windows Server 2012 R2. We are looking to expose SOAP services secured using Kerberos.
So far we have created a Service account in AD and associated it to a SPN.
SOAP service is hosted on Server1.example.com & SPN is set to HTTP/Server1.example.com.
Key Tab file has been generated for this Service account and the same has been configured in Kerberos krb5.ini configuration file. The Service account has AES 256/AES 128 Support enabled and Keytab file is generated with support for all crypto encryption types.
Policy Set & a Policy Binding has been configured as per the below link and is associated with the message flow.
All the steps suggested in the infocenter has been followed, but still unable to successfully authenticate a client user to access the SOAP Service.
https://www.ibm.com/support/knowledgecenter/en/SSKM8N_8.0.0/com.ibm.etools.mft.doc/bc49108_.htm
https://www.ibm.com/developerworks/websphere/library/techarticles/1103_haxby/1103_haxby.html
I'm using SOAP UI to test this SOAP Service and SOAP UI has been configured as per this link
https://www.soapui.org/soap-and-wsdl/spnego/kerberos-authentication.html
I also tried invoking this service from a Java Client, but still couldnt figure out why authentication fails.
Queries :
1. Should a Service principal name for Broker Service include a port name while registering them in KDC (say HTTP/Server1.example.com:8805@EXAMPLE.COM)? We have used free range ports (8800 - 8820) for exposing broker services in a server. Does that mean 20 SPN required for a Server ?
2. Should the Service Principal name be registered against the User ID on which broker service is running ?
3. Do we need a security profile to be associated with the flow ? I'm not looking to extract identity and propagate them to downstream nodes.
If any body had configured Kerberos Secured service in your projects, please advice/provide suggestions. Not much info found on infocenter commenting on guidelines for setting SPN for broker services.
Thank you
Ram |
|
| Back to top |
|
 |
| rama91 |
| Posted: Thu Sep 26, 2019 10:46 am Post subject: |
|
|
Novice
Joined: 28 Aug 2019
Posts: 15
|
I have adopted the following steps to setup Integrated Windows Authentication - Kerberos on SOAP Services hosted on broker. Inspite of having all configurations as per the info center, still unable to successfully authenticate a client user using kerberos. Can someone please look at the steps and point me in right direction. Thank you.
1) KDC Side :-
Created a client user SRVIIBCli in AD. User account has no SPN, enabled "do not require pre-authentication", checked AES 256/128 support.
Create a Service account SRVIIBADPrincipal in AD. Service account represents broker. UPN set to "HTTP/SRVIIBADPrincipal". The broker is running on a different service account "SRVIIBService". The following SPN's are tied to this Service account
| Code: |
ktpass -princ "HTTP/SRVIIBADPrincipal@AD.CO.UK" -mapop set -mapuser SRVIIBADPrincipal -pass <> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out srviibadprincipal.keytab
ktpass -princ "HTTP/d003.ad.co.uk:8805@AD.CO.UK" -mapop add -mapuser SRVIIBADPrincipal -pass <> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -in srviibadprincipal.keytab -out srviibadprincipal.keytab -setupn |
Both the User accounts has "Password No Expire" & "User cannot change password"
2) Broker Service Provider Configuration
SOAP Service is deployed in an EG enabled with embedded listener. Execution Group JVM Setting configured with Kerberos ini file/keytab file location.
| Code: |
mqsichangeproperties BROKER -e KerberosTestEG -o ComIbmJVMManager -n kerberosConfigFile -v "C:\Windows\krb5.ini"
mqsichangeproperties BROKER -e KerberosTestEG -o ComIbmJVMManager -n kerberosKeytabFile -v "C:\Windows\srviibadprincipal_24092019.keytab"
mqsichangeproperties BROKER -e KerberosTestEG -o ComIbmJVMManager -n jvmSystemProperty -v "-Djava.security.krb5.conf=C:\Windows\krb5.ini" |
Inbound HTTPSConnector enabled with IWA
| Code: |
| mqsichangeproperties BROKER -e KerberosTestEG -o HTTPSConnector -n integratedWindowsAuthentication -v "Negotiate:Kerberos" |
Restarted the Broker after configuring the above.
3) To test the broker service, developed a test application and configured IWA for consuming the Provider service. Generated a keytab for client user using ktab java utility.
| Code: |
mqsichangeproperties BROKER -e KerberosConsumerEG -o ComIbmSocketConnectionManager -n allowedAuthTypes -v "Nego2;Negotiate"
mqsichangeproperties BROKER -e KerberosConsumerEG -o ComIbmSocketConnectionManager -n preemptiveAuthType -v "Negotiate"
mqsichangeproperties BROKER -e KerberosConsumerEG -o ComIbmSocketConnectionManager -n allowNtlmNegotiation -v 'FALSE'
mqsichangeproperties BROKER -e KerberosConsumerEG -o ComIbmSocketConnectionManager -n negotiateMutualAuth -v TRUE
mqsichangeproperties BROKER -e KerberosConsumerEG -o ComIbmJVMManager -n kerberosConfigFile -v "C:\Windows\krb5.ini"
mqsichangeproperties BROKER -e KerberosConsumerEG -o ComIbmJVMManager -n kerberosKeytabFile -v "C:\Users\krb5.keytab"
mqsisetdbparms BROKER -n kerberos::AD.CO.UK::KerberosConsumerEG -u SRVIIBCli -p password
mqsisetdbparms BROKER -n kerberosSecurityID -u SRVIIBCli -p password
mqsicreateconfigurableservice BROKER -c SecurityProfiles -o kerberosSecurityProfile -n "propagation,idToPropagateToTransport,transportPropagationConfig" -v "TRUE,STATIC ID,kerberosSecurityID" |
Consumer application deployed with the above security profile. The above configuration works for NTLM and fails for Kerberos authentication. Following errors captured from service Trace.
| Quote: |
ImbHTTPHeaderParser::chunkedTransferEncoding 'Transfer-Encoding header found:' , 'chunked'
2019-09-25 17:57:19.920246 29516 >> } ImbHTTPHeaderParser::chunkedTransferEncoding , true
2019-09-25 17:57:19.920252 29516 >> ImbWSRequest::readDataFromSocket 'Processed First Chunk: size, headerLen' , 0, 1
2019-09-25 17:57:19.920256 29516 >> ImbWSRequest::readDataFromSocket 'Processed Final First Chunk: totalChunkedDataLength' , 0
2019-09-25 17:57:19.920260 29516 >> } ImbWSRequest::readDataFromSocket , 0
2019-09-25 17:57:19.920266 29516 >> } ImbWSRequest::getHttpResponse , 4
2019-09-25 17:57:19.920270 29516 >> { ImbHTTPHeaderParser::getAuthenticateHeaderData , 8, false
2019-09-25 17:57:19.920274 29516 >> { ImbRFC822HeaderParser::getHeaderValueInternal const , false
2019-09-25 17:57:19.920278 29516 >> } ImbRFC822HeaderParser::getHeaderValueInternal const
2019-09-25 17:57:19.920282 29516 >> ImbHTTPHeaderParser::getAuthenticateHeaderData 'WWW-Authenticate Header' , 'Negotiate'
2019-09-25 17:57:19.920286 29516 >> ImbHTTPHeaderParser::getAuthenticateHeaderData 'Found Authtype' , 'negotiate', 'Negotiate'
2019-09-25 17:57:19.920292 29516 >> } ImbHTTPHeaderParser::getAuthenticateHeaderData , 'No matching Authorization Header data found'
2019-09-25 17:57:19.920296 29516 >> { ImbHTTPHeaderParser::getAuthenticateHeaderType
2019-09-25 17:57:19.920300 29516 >> { ImbRFC822HeaderParser::getHeaderValueInternal const , false
2019-09-25 17:57:19.920302 29516 >> } ImbRFC822HeaderParser::getHeaderValueInternal const
2019-09-25 17:57:19.920306 29516 >> ImbHTTPHeaderParser::getAuthenticateHeaderType 'WWW-Authenticate Header' , 'Negotiate'
2019-09-25 17:57:19.920310 29516 >> { ImbSocketManager::socketManager
2019-09-25 17:57:19.920314 29516 >> } ImbSocketManager::socketManager
2019-09-25 17:57:19.920318 29516 >> ImbHTTPHeaderParser::getAuthenticateHeaderType 'Found Authtype' , 'negotiate', 'Negotiate'
2019-09-25 17:57:19.920322 29516 >> { ImbSocketManager::authTypeSupported , 24, 8
2019-09-25 17:57:19.920326 29516 >> } ImbSocketManager::authTypeSupported , true
2019-09-25 17:57:19.920330 29516 >> } ImbHTTPHeaderParser::getAuthenticateHeaderType , 8
2019-09-25 17:57:19.920336 29516 >> { ImbWSRequest::fillinAuthenticationCredentialsForServer , 8, false, 0, 0
2019-09-25 17:57:19.920342 29516 >> { ImbClientAuthDetails::ImbClientAuthDetails , false
2019-09-25 17:57:19.920346 29516 >> } ImbClientAuthDetails::ImbClientAuthDetails
2019-09-25 17:57:19.920492 29516 >> { ImbAuthDetails::logTimestamp , 9223371172854800383
2019-09-25 17:57:19.920500 29516 >> ImbAuthDetails::logTimestamp 'Timestamp is effectively INFINITE' , 'AcquireCredentialsHandle Expiry'
2019-09-25 17:57:19.920504 29516 >> } ImbAuthDetails::logTimestamp
2019-09-25 17:57:19.920508 29516 >> { ImbWSRequestParameters::getServicePrincipalName , false
2019-09-25 17:57:19.920512 29516 >> } ImbWSRequestParameters::getServicePrincipalName , 'HTTP/d003.ad.co.uk:8805'
2019-09-25 17:57:19.920794 29516 >> { ImbAuthDetails::logTimestamp , 132139081399200543
2019-09-25 17:57:19.920804 29516 >> ImbAuthDetails::logTimestamp 'msg - D/M/Y - H:M:S:M' , 'AcceptSecurityContext Expiry', 25, 9, 2019, 18, 2, 19, 920
2019-09-25 17:57:19.920808 29516 >> } ImbAuthDetails::logTimestamp
2019-09-25 17:57:19.920812 29516 >> ImbWSRequest::fillinAuthenticationCredentialsForServer 'Client inputAttributes and outputAttributes' , 2318, 4352
2019-09-25 17:57:19.920816 29516 >> { ImbClientAuthDetails::authPackage , false
2019-09-25 17:57:19.920824 29516 >> ImbClientAuthDetails::authPackage 'PackageName, comment, state, flag' , 'NTLM', 'NTLM Security Package', 0, 42478391
2019-09-25 17:57:19.920828 29516 >> } ImbClientAuthDetails::authPackage , 'NTLM'
2019-09-25 17:57:19.920834 29516 >> { ImbSocketManager::allowNtlmAuth
2019-09-25 17:57:19.920838 29516 >> } ImbSocketManager::allowNtlmAuth , false
2019-09-25 17:57:19.920842 29516 >> ImbWSRequest::fillinAuthenticationCredentialsForServer 'NTLM package found, but NTLM not allowed by user.' , 'NTLM', false, false
2019-09-25 17:57:19.920846 29516 >> { ImbClientAuthDetails::~ImbClientAuthDetails
2019-09-25 17:57:19.920848 29516 >> } ImbClientAuthDetails::~ImbClientAuthDetails
2019-09-25 17:57:19.920862 29516 >> ImbWSRequest::fillinAuthenticationCredentialsForServer 'InitializeSecurityContextW return' , false, 590610, 'The function completed successfully but must be called again to complete the context
', 'NTLM', false, 0
2019-09-25 17:57:19.920868 29516 >> } ImbWSRequest::fillinAuthenticationCredentialsForServer , false
2019-09-25 17:57:19.920872 29516 >> ImbWSRequest::makeWSRequest 'Authentication Failed' , false, false
2019-09-25 17:57:19.920876 29516 >> { ImbWSRequest::storeSocket , false, false
2019-09-25 17:57:19.920880 29516 >> { ImbHTTPHeaderParser::connectionClose
2019-09-25 17:57:19.920884 29516 >> { ImbRFC822HeaderParser::getHeaderValueInternal , false
2019-09-25 17:57:19.920888 29516 >> } ImbRFC822HeaderParser::getHeaderValueInternal
2019-09-25 17:57:19.920892 29516 >> } ImbHTTPHeaderParser::connectionClose , 'No Connection Header found'
2019-09-25 17:57:19.920900 29516 >> { ImbSocketManager::manageSocket , (*ptr)d384db4390, 'd003.ad.co.uk', 8805, 'TLSv1.2', '', '', '', ''
2019-09-25 17:57:19.920944 29516 >> ImbWSRequest::makeWSRequest file:F:\build\S1000_slot1\S1000_P\src\WebServices\WSLibrary\ImbWSRequest.cpp line:689 message:3634.BIPmsgs 'Received HTTP data' , 'SOAP Request', 'd003.ad.co.uk', 401
2019-09-25 17:57:19.920944 29516 >> UserTrace BIP3634I: Node 'SOAP Request' received HTTP data from host 'd003.ad.co.uk' with status code of 401. |
Questions:-
1. Why broker wont form the Negotiate Headers needed for Kerberos authentication. ?
2. Running a service trace on Service Provider flow captures nothing.
Thank you for reading till the end. Any thing else needed to make it work ? |
|
| Back to top |
|
|
| prasadpav |
| Posted: Fri Sep 27, 2019 2:20 am Post subject: |
|
|
Centurion
Joined: 03 Oct 2004
Posts: 142
|
| Quote: |
| } ImbWSRequestParameters::getServicePrincipalName , 'HTTP/d003.ad.co.uk:8805' |
The shows that you definitely need the port number specified in your SPN.
| Quote: |
| UPN set to "HTTP/SRVIIBADPrincipal". |
I'm struggling myself to get the Kerberos setup working but from what I gather so far this SPN doesn't appear to be correct. I would change it to "HTTP/d003.ad.co.uk:8805" and try it out.
| Quote: |
| ktpass -princ "HTTP/SRVIIBADPrincipal@AD.CO.UK" -mapop set -mapuser SRVIIBADPrincipal -pass <> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out srviibadprincipal.keytab |
Since your broker is running using AD user - SRVIIBService and kerberos AD user is - SRVIIBADPrincipal, I had hoped yours ktpass command should be:
| Quote: |
| ktpass -princ "HTTP/SRVIIBADPrincipal@AD.CO.UK" -mapop set -mapuser SRVIIBService <> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out srviibadprincipal.keytab |
Have your created any security profiles for Authentication and Authorisation? If so, if you don't mind, could you paste how your configuration looked like please? |
|
| Back to top |
|
|
| rama91 |
| Posted: Sun Sep 29, 2019 9:28 am Post subject: |
|
|
Novice
Joined: 28 Aug 2019
Posts: 15
|
Thanks for your reply.
| Quote: |
| The shows that you definitely need the port number specified in your SPN. |
| Code: |
ktpass -princ "HTTP/SRVIIBADPrincipal@AD.CO.UK" -mapop set -mapuser SRVIIBADPrincipal -pass <> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out srviibadprincipal.keytab
ktpass -princ "HTTP/d003.ad.co.uk:8805@AD.CO.UK" -mapop add -mapuser SRVIIBADPrincipal -pass <> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -in srviibadprincipal.keytab -out srviibadprincipal.keytab -setupn |
Most of the online blogs say that SPN & UPN should match. So had set a SPN with service account name , HTTP/SRVIIBADprincipal. Additionally had set another SPN HTTP/d003.ad.co.uk:8805 to the same service account.
| Quote: |
Since your broker is running using AD user - SRVIIBService and kerberos AD user is - SRVIIBADPrincipal, I had hoped yours ktpass command should be:
Quote:
ktpass -princ "HTTP/SRVIIBADPrincipal@AD.CO.UK" -mapop set -mapuser SRVIIBService <> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out srviibadprincipal.keytab |
Had asked my KDC admin to create another keytab file for SRVIIBService account and remove existing SPN's that are set to SRVIIBADprincipal. will update results after test.
| Quote: |
| Have your created any security profiles for Authentication and Authorisation? If so, if you don't mind, could you paste how your configuration looked like please? |
I did try both with/without security profiles. Didnt work in either cases. I'm just looking to authenticate users and no lookup to LDAP groups for authorization. Security profile looks this way
| Code: |
G:\Program Files\IBM\IIB\10.0.0.12>mqsireportproperties SERVICE_TIER_1 -c SecurityProfiles -o kerberosSecurityProfileProvider -r
SecurityProfiles
kerberosSecurityProfileProvider
authentication='LDAP'
authenticationConfig='ldap://AD.CO.UK:389/DC=ad,DC=domain,DC=co,DC=uk?sAMAccountName'
authorization='NONE'
authorizationConfig=''
idToPropagateToTransport='STATIC ID'
keyStore='Reserved for future use'
mapping='NONE'
mappingConfig=''
passwordValue='PLAIN'
propagation='TRUE'
rejectBlankpassword='TRUE'
transportPropagationConfig='KRBSecurityID'
trustStore='Reserved for future use'
mqsisetdbparms SERVICE_TIER_1 -n KRBSecurityID -u SRVIIBADPrincipal -p password |
It's so frustrating that nothing is captured in service/user trace for provider flows, consumer flows just provide generic error information. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
