|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
AD authentication 401 error |
« View previous topic :: View next topic » |
Author |
Message
|
saviobarr |
Posted: Thu Jun 02, 2016 6:09 am Post subject: AD authentication 401 error |
|
|
Centurion
Joined: 21 Oct 2014 Posts: 100 Location: Sao Paulo, Brazil
|
Hi everyone,
I created a security profile in order to enable AD based authentication. I took the following steps:
1 - Created a security profile. I set the authenticationConfig property passing the IP and port of my AD server. It looks like below:
authenticationConfig: LDAP://192.168.172.195:389/CN=Users,DC=testead,DC=local?sAMAccountName
2 - I issued a mqsisetdbparms command like below:
mqsisetdbparms TEST_AUTH -n ldap::192.168.172.195 -u CN=Administrator,CN=Users,DC=testead,DC=local -p p4ssw0rd
3 - I stopped and started the Integration Node
4 - On my bar file I set the Security Profile Name property passing the security profile name and deployed it with no problems.
Unfortunately when I tested it on SoapUI, using basic security, I took the error "401 Authorization Required". On SoapUI provided the user Administrator and
password p4ssw0rd
Is there any missing or wrong step?
Many thanks
Savio _________________ Go as far as you can go. Then go farther!
Last edited by saviobarr on Thu Jun 02, 2016 8:44 am; edited 1 time in total |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jun 02, 2016 6:22 am Post subject: Re: AD authentication 401 error |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
saviobarr wrote: |
Hi everyone,
I created a security profile in order to enable AD based authentication. I took the following steps:
1 - Created a security profile. I set the authenticationConfig property passing the IP and port of my AD server. I looks like below:
authenticationConfig: LDAP://192.168.172.195:389/CN=Users,DC=testead,DC=local?sAMAccountName
2 - I issued a mqsisetdbparms command like below:
mqsisetdbparms TEST_AUTH -n ldap::192.168.172.195 -u CN=Administrator,CN=Users,DC=testead,DC=local -p p4ssw0rd
3 - I stopped and started the Integration Node
4 - On my bar file I set the Security Profile Name property passing the security profile name and deployed it with no problems.
Unfortunately when I tested it on SoapUI, using basic security, I took the error "401 Authorization Required". On SoapUI provided the user Administrator and
password p4ssw0rd
Is there any missing or wrong step?
Many thanks
Savio |
What is the URL of the infocenter part you used to setup the ldap?
I don't believe your ldap is setup right, and certainly the mqsisetdbparms command looks all wrong.... shouldn't it say -n ldap::sAMAccountName or something of the kind??  _________________ MQ & Broker admin |
|
Back to top |
|
 |
saviobarr |
Posted: Thu Jun 02, 2016 6:29 am Post subject: Re: AD authentication 401 error |
|
|
Centurion
Joined: 21 Oct 2014 Posts: 100 Location: Sao Paulo, Brazil
|
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jun 02, 2016 8:27 am Post subject: Re: AD authentication 401 error |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
[/quote]
Read again, you did not. The parms you gave are part of the configurable service...
mqsisetdbparms integrationNode -n ldap::hostname -u user -p passwd is the way the command should be done.... You've added quite a bit of stuff there...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
saviobarr |
Posted: Thu Jun 02, 2016 8:42 am Post subject: |
|
|
Centurion
Joined: 21 Oct 2014 Posts: 100 Location: Sao Paulo, Brazil
|
Hi fjb_saper,
Thanks for replying... I am not getting the missing point
Command syntax:
mqsisetdbparms integrationNode -n ldap::hostname -u user -p passwd
What I did:
mqsisetdbparms TEST_AUTH -n ldap::192.168.172.195 -u CN=Administrator,CN=Users,DC=testead,DC=local -p p4ssw0rd
Where:
integrationNode: TEST_AUTH
-n ldap::hostname: ldap::192.168.172.195
-u user: CN=Administrator,CN=Users,DC=testead,DC=local
-p passwd: p4ssw0rd _________________ Go as far as you can go. Then go farther! |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jun 02, 2016 8:49 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
saviobarr wrote: |
Hi fjb_saper,
Thanks for replying... I am not getting the missing point
Command syntax:
mqsisetdbparms integrationNode -n ldap::hostname -u user -p passwd
What I did:
mqsisetdbparms TEST_AUTH -n ldap::192.168.172.195 -u CN=Administrator,CN=Users,DC=testead,DC=local -p p4ssw0rd
Where:
integrationNode: TEST_AUTH
-n ldap::hostname: ldap::192.168.172.195
-u user: CN=Administrator,CN=Users,DC=testead,DC=local
-p passwd: p4ssw0rd |
Well it looks like you are mixing 2 parts. The part where the user is defined is in the configurable service and in the dbparms you are expected to only enter Administrator if that is the user to access the ldap. _________________ MQ & Broker admin |
|
Back to top |
|
 |
saviobarr |
Posted: Thu Jun 02, 2016 9:04 am Post subject: |
|
|
Centurion
Joined: 21 Oct 2014 Posts: 100 Location: Sao Paulo, Brazil
|
saviobarr wrote: |
Hi fjb_saper,
Thanks for replying... I am not getting the missing point
Command syntax:
mqsisetdbparms integrationNode -n ldap::hostname -u user -p passwd
What I did:
mqsisetdbparms TEST_AUTH -n ldap::192.168.172.195 -u CN=Administrator,CN=Users,DC=testead,DC=local -p p4ssw0rd
Where:
integrationNode: TEST_AUTH
-n ldap::hostname: ldap::192.168.172.195
-u user: CN=Administrator,CN=Users,DC=testead,DC=local
-p passwd: p4ssw0rd |
Quote: |
Well it looks like you are mixing 2 parts. The part where the user is defined is in the configurable service |
Yes. In the SecurityProfile, the user is expected to be passed in the sAMAccountName param in the authenticationConfig attribute:
authenticationConfig: LDAP://192.168.172.195:389/CN=Users,DC=testead,DC=local?sAMAccountName
Quote: |
and in the dbparms you are expected to only enter Administrator if that is the user to access the ldap. |
I tried -u Administrator and had the same problem. Btw, Administrator is the user to access the LDAP... error still remains :'( annoying problem... _________________ Go as far as you can go. Then go farther! |
|
Back to top |
|
 |
martinb |
Posted: Fri Jun 03, 2016 5:37 am Post subject: |
|
|
Master
Joined: 09 Nov 2006 Posts: 210 Location: UK
|
Hi,
Several points to consider
1) You do not state why IIB is actually rejecting the authentication request, the 401 returned to the client could be for a number of reasons.
As per Diagnosing security problems you need to be collecting user trace from the IIB runtime to get the underlying LDAP failure reason, it's not returned to the external client for obvious reasons.
2) There are two identities that need to bind to LDAP here
a) The identity passed into the flow with the message instance
b) Because AD does not accept anonymous binds, IIB's security manager needs an identity to connect to LDAP to perform a pre-lookup to convert the received per message identity into a full DN to bind. This is the identity you are setting via mqsisetdbparms with the "-n ldap::<...>".
3) Looks like you should also have "?sub" on your Security profile authenticationConfig. Since you are using sAMAccountName, which is an extended attribute, so IIB security manager has to resolve this into a full DN for the identity to issue the bind to determine if the input message should be allowed to flow
4) When you provide the LDAP identity for the IIB security manager to bind to LDAP via mqsisetdbparms the "-u" param needs to be a full DN that the LDAP server will accept a bind with. AD also accepts binds using a domain qualified ID. So I'd expect you to be using something like "-u <MyDomain>/<MyID>"
HTH |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Jun 03, 2016 6:20 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
saviobarr wrote: |
saviobarr wrote: |
Hi fjb_saper,
Thanks for replying... I am not getting the missing point
Command syntax:
mqsisetdbparms integrationNode -n ldap::hostname -u user -p passwd
What I did:
mqsisetdbparms TEST_AUTH -n ldap::192.168.172.195 -u CN=Administrator,CN=Users,DC=testead,DC=local -p p4ssw0rd
Where:
integrationNode: TEST_AUTH
-n ldap::hostname: ldap::192.168.172.195
-u user: CN=Administrator,CN=Users,DC=testead,DC=local
-p passwd: p4ssw0rd |
Quote: |
Well it looks like you are mixing 2 parts. The part where the user is defined is in the configurable service |
Yes. In the SecurityProfile, the user is expected to be passed in the sAMAccountName param in the authenticationConfig attribute:
authenticationConfig: LDAP://192.168.172.195:389/CN=Users,DC=testead,DC=local?sAMAccountName
Quote: |
and in the dbparms you are expected to only enter Administrator if that is the user to access the ldap. |
I tried -u Administrator and had the same problem. Btw, Administrator is the user to access the LDAP... error still remains :'( annoying problem... |
As you have commas and other stuff in your userid have you tried using
-u "userid" i.e. setting the userid with quotes around it?
Also please check out martinb's post which is very enlightening  _________________ MQ & Broker admin |
|
Back to top |
|
 |
saviobarr |
Posted: Fri Jun 03, 2016 7:17 am Post subject: |
|
|
Centurion
Joined: 21 Oct 2014 Posts: 100 Location: Sao Paulo, Brazil
|
Quote: |
1) You do not state why IIB is actually rejecting the authentication request, the 401 returned to the client could be for a number of reasons. |
I got this reason from user trace:
<UserTrace timestamp="2016-06-03 14:48:20.006790" thread="3092" function="MbLDAPSecurityProvider.getUserDNFromBrokerBind" text="'User does not exist'" catalog="BIPmsgs" number="2703" file="F:\build\slot1\S000_P\src\DataFlowEngine\NativeTrace\ImbNativeTrace.cpp" line="170">
<Insert type="string">'Username and password'</Insert>
<Insert type="string">'testauth'</Insert>
<Insert type="string">''</Insert>
<Insert type="string">'ldap://localhost:389'</Insert>
<Insert type="string">'TEST_AUTH_MF'</Insert>
</UserTrace>
The issue is: this user DOES exist =\
Quote: |
2) There are two identities that need to bind to LDAP here
a) The identity passed into the flow with the message instance
b) Because AD does not accept anonymous binds, IIB's security manager needs an identity to connect to LDAP to perform a pre-lookup to convert the received per message identity into a full DN to bind. This is the identity you are setting via mqsisetdbparms with the "-n ldap::<...>". |
Yes, I am biding with domain admin and in the message I am passing a valid user/pwd, setting it in SoapUi Basic Autentication
Quote: |
3) Looks like you should also have "?sub" on your Security profile authenticationConfig. Since you are using sAMAccountName, which is an extended attribute, so IIB security manager has to resolve this into a full DN for the identity to issue the bind to determine if the input message should be allowed to flow |
In the SoapUi request I also tried CN=testauth,CN=Users,DC=testead,DC=local
Quote: |
4) When you provide the LDAP identity for the IIB security manager to bind to LDAP via mqsisetdbparms the "-u" param needs to be a full DN that the LDAP server will accept a bind with. AD also accepts binds using a domain qualified ID. So I'd expect you to be using something like "-u <MyDomain>/<MyID>" |
Should I provide either testead/CN=Administrator or testead/Administrator? _________________ Go as far as you can go. Then go farther! |
|
Back to top |
|
 |
martinb |
Posted: Fri Jun 03, 2016 10:39 am Post subject: |
|
|
Master
Joined: 09 Nov 2006 Posts: 210 Location: UK
|
Hi,
From what you've shown it looks like
- IIB security manager did successfully bind to AD
If it had not I'd expect to have seen a BIP272
I would use mqsisetdbparms ... -u testead/Administrator ...
But perhaps you've found just -u Administrator works?, perhaps if your machine is in that domain.
- The BIP 2703 "User does not exist" you got, I believe means IIB can't locate a user entry with sAMAccountName = testauth, when it trys to get the required full DN to use with the password from the input message.
As I said before I would have set my security profile with something more like:
authenticationConfig: LDAP://192.168.172.195:389/DC=testead,DC=local?sAMAccountName?sub |
|
Back to top |
|
 |
saviobarr |
Posted: Fri Jun 03, 2016 11:57 am Post subject: |
|
|
Centurion
Joined: 21 Oct 2014 Posts: 100 Location: Sao Paulo, Brazil
|
Solved! Finally! I set the property idToPropagateToTransport=STATIC ID. martinb, your advice to keep eyes on user trace made everything easier. Many thanks. If someone need do the same config, my configs are:
mqsireportproperties TESTNode_Administrator -c SecurityProfiles -o AD_auth -r
SecurityProfiles
AD_auth
authentication='LDAP' authenticationConfig='ldap://AD_HOST:389/CN=Users,DC=testead,DC=local?sAMAccountName'
authorization='NONE'
authorizationConfig=''
idToPropagateToTransport='STATIC ID'
keyStore='Reserved for future use'
mapping='NONE'
mappingConfig=''
passwordValue='PLAIN'
propagation='TRUE'
rejectBlankpassword='FALSE'
transportPropagationConfig=''
trustStore='Reserved for future use'
mqsisetdbparms TESTNODE_Administrator -n ldap::AD_HOST -u CN=Administrator,CN=Users,DC=testead,DC=local -p Passw0rd
Have a nice weekend _________________ Go as far as you can go. Then go farther! |
|
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
|
|
|
|