How to properly configure Kerberos principal name - ibm-mq

this is my krb5.ini file.
[libdefaults]
default_realm = TEST.EXAMPLE.COM
.....
[realms]
TEST.EXAMPLE.COM = {
kdc = test.example.com:88
master_kdc = test.example.com:88
default_domain = example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
I created a user USERA on the domain, created a credential using kinit and have my jaas.config file defined as
example_config {
com.ibm.security.auth.module.Krb5LoginModule required
useDefaultCcache=false
principal="userA#TEST.EXAMPLE.COM"
useCcache="file:///c:/Users/userA/krb5cc_userA"
debug=true;
};
everything seems ok as it gets authenticated.
[JGSS_DBG_CRED] Retrieving Kerberos creds from cache for principal=userA#TEST.EXAMPLE.COM
[JGSS_DBG_CRED] Non-interactive login; no callbacks necessary.
[JGSS_DBG_CRED] Done retrieving Kerberos creds from cache
[JGSS_DBG_CRED] Login successful
[JGSS_DBG_CRED] userA#TEST.EXAMPLE.COM added to Subject
[JGSS_DBG_CRED] Kerberos ticket for userA#TEST.EXAMPLE.COM added to Subject
[JGSS_DBG_CRED] No keys to add to Subject for userA#TEST.EXAMPLE.COM
however now, I am trying to use a service principal name , instead of user principal. I used ktpass to create a keytab file
ktpass -out "c:\mytab.keytab" -princ "Installation1/test.example.com#TEST.EXAMPLE.COM" -mapUser "TEST\userA" -mapOp set -pass password -crypto DES-CBC-MD5 -pType KRB5_NT_PRINCIPAL +DesOnly
and then use setspn to check
C:\>setspn -l userA
Registered ServicePrincipalNames for CN=userA,CN=Users,DC=test,DC=example,DC=com:
Installation1/test.example.com
i change my config to
example_config{
com.ibm.security.auth.module.Krb5LoginModule required
credsType = both
principal="userA/test.example.com"
useDefaultCcache = true
useDefaultKeytab = false
useKeytab = "file:///c:/mytab.keytab"
debug=true;
};
now when i run my app, it gives
[JGSS_DBG_CRED] Retrieving Kerberos creds from keytab for principal=Installation1/test.example.com
[JGSS_DBG_CRED] Service name=Installation1/test.example.com#TEST.EXAMPLE.COM
[JGSS_DBG_CRED] Check for Default keytab :
[JGSS_DBG_CRED] No Kerberos creds in keytab for principal Installation1/test.example.com
[JGSS_DBG_CRED] No service key in keytab; login failed
What did i do wrong in the config file? or is there something i miss in the ktpass command? Installation1 is the service name (of Websphere MQ) when I go to check Control Panel -> Services. I want to autheticate userA to use Websphere MQ service. (like if i want to let user use HTTP I would put principal as HTTP/.....TEST.EXAMPLE.COM
thanks

There is nothing in MQ that performs authentication. MQ only performs authorization (permission lookup) via its OAM module.
For a default install of MQ (on any platform including z/OS), there is no effective security in MQ. You can configure MQ to use MQ SSL between a client application and the queue manager (or between 2 queue managers).
The other choice is to purchase a 3rd party MQ security solution like MQAUSX which handles authentication to various targets.

Related

IBM MQ: AMQ7026E: A principal or group name was invalid

I am getting below error when I am executing setmqaut on IBM-MQ queue manager
bash-4.4$ setmqaut -m QM1 -t qmgr -p mqadmin +connect
AMQ7026E: A principal or group name was invalid.
The error basically returns that MQ was not able to find user 'mqadmin'. Please check the queue manager CONNAUTH value for the configured authentication method. If the default 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' is used then check within the machine to see if the user 'mqadmin' is available. If you are using LDAP for authentication then check if that 'mqadmin' is available on ldap server and MQ is able to contact ldap server.

Kerberos HTTP service Using GSS shows No valid credentials due to domain name or host name mismatch

I am having a Micro-Service Platform having multiple Micro-Services connected to each other, Platform uses Kerberos for authentication of Micro-Services. In One of Micro-Service Node hadoop is installed which uses separate KDC for Hadoop cluster authentication.
Lets say platform domain is "idm.com" and hadoop domain is "hadoop.com".
Resource Manager is running on one node. I have configure HTTP principal for spnego in core-site.xml using "hadoop.http.authentication.kerberos.principal" property to "HTTP/master.hadoop.com#HADOOP.COM" and nodes Hostname is "hadoopmaster.idm.com".
I do Kinit and acquire root user ticket from TGS. When I tried to do curl using "curl -k -v --negotiate -u : https://master.hadoop.com:8090/cluster" It shows GSS Exception: No valid credentials provided.
If I see klist it shows two ticket one krbtgt and second "HTTP/hadoopmaster.idm.com#HADOOP.COM"(I have added this principal in kdc database). First krbtgt i got using kinit and second HTTP one i Got it automatically after doing curl before curl the ticket was not there. Krb client acquired another for using HTTP service.
After some debugging I noticed the problem/behaviour is I got ticket for HTTP/hadoopmaster.idm.com#HADOOP.COM where I have configure hadoop to use HTTP/master.hadoop.com#HADOOP.COM. If we configure hadoop to use "HTTP/hadoopmaster.idm.com#HADOOP.COM" then ui is accessible.
I have added both FQDNs to /etc/hosts file.
It seems when I do curl using any of the FQDNs I got the HTTP ticket of the first entry in /etc/hosts file.
For example if
...
10.7.0.5 hadoopmaster.idm.com
10.7.0.5 master.hadoop.com
...
now if i do curl i will get HTTP/hadoopmaster.idm.com#HADOOP.COM in klist.
and if /etc/hosts looks like this
...
10.7.0.5 master.hadoop.com
10.7.0.5 hadoopmaster.idm.com
...
Now if i do curl i will get HTTP/master.hadoop.com in klist
In both the cases if i configure the hadoop property to the same i got using curl then UI will be accessible and other wise it will shows 403 GSSException which i guess means curl used spnego but didn't get valid credentials.
And if it matches with the hadoop's configured principal then it will work.
It looks like Hostname is causing problem is there any way to map this hostname or is there any kerberos config which can map this or any property which will give me exact ticket with exact hostname i have specified in curl despite of hadoop configurations.

kcadm created client is always unauthorized

I am trying to automate setting up of a Keycloak server for an application. Part of that is to set up a Keycloak client using the admin CLI:
kcadm.sh create clients -r MyRealm -s clientId=my-client -s enabled=true
That seems to work; I can see the client is present using the admin console. However, if I try to use that client with the Java client (creating a Keycloak object) even a read-only operation fails due to HTTP 401 Unauthorized. What am I doing wrong?
After much experimenting, I discovered the cause of the problem. If you create a client using the UI, the UI sets the client to be public client with direct access grants enabled by default. The admin CLI however does not, and that results in access through the Java client being denied. You must instead explicitly set those when you create the client using the admin CLI:
kcadm.sh create clients -r MyRealm -s clientId=mc-client -s enabled=true -s directAccessGrantsEnabled=true -s publicClient=true

Kerberos create spn and keytabs to include proxy DNS

I want to create SPNs and keytabs to include the proxy DNS so that the proxy can forward the headers to the back-end. I'm unsure what is host, domain and realm. Can someone verify if it looks ok? Or did I add an example.com too much?
The proxy has the server name configured as testing.example.com
The realm is example.com
setspn -a HTTP/testing.example.com testinghttp
setspn -a HTTP/testing.example.com.example.com testinghttp
ktpass -princ HTTP/testing.example.com.example.com#example.com -pass Password -mapuser example\testinghttp -crypto ALL -ptype KRB5_NT_PRINCIPAL -out d:\temp\key.keytab -kvno 0
Assuming that the proxy is in the same domain, all you need to know is the face url of proxy. Use this face url as the SPN value. Assuming your proxy face url is http://testing.example.com, the command setspn -a HTTP/testing.example.com testinghttp is correct.
Moreover, if you are generating keytab, then you need not execute the above command. The SPN specified in ktpass (which is proxy face url) is automatically attached to the given user. Also the user's UPN changes to this SPN value.
Proxy will (it must) redirect the request 'as is' (with all the headers) to the end node/server.
On receiving end (server), you need to accept the ticket present in 'Negotiate' header. You have to use the keytab (and its password) generated above for this.

hydra target ssh does not support password authentication

I am using Hydra v8.1 downloaded and compiled from a tar file. I've managed to solve the standard problem of libssh support and now when I try to make an attack(I think it's called dictionary attack) on an SSH server, after specifying the following command:
hydra -l {username} -s {port} -P /Users/{UserName}/Desktop/{file}.txt {ip} ssh
I get the following output:
Hydra v8.1 (c) 2014 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (http://www.thc.org/thc-hydra) starting at 2015-09-30 10:59:49
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 7 tasks per 1 server, overall 64 tasks, 7 login tries (l:1/p:7), ~0 tries per task
[DATA] attacking service ssh on port {port}
[ERROR] target ssh://{ip}:{port}/ does not support password authentication
I have enabled support for the required libraries and I am running an OS X environment.
Can someone indicate a solution to this problem? Thank you.
Note: If I manually log in with the username and password, the authentication grants access to the server.
from another board:
https://security.stackexchange.com/questions/183848/hydra-fails-with-error-target-ssh-192-168-16-12822-does-not-support-passw
SSH supports several different authentication mechanisms. The password authentication mechanism has the client send the password to the server as a password. The more-common keyboard-interactive authentication mechanism opens a channel between the client and an authentication process on the server. The client allows the user to directly interact with the authentication process, which is usually just a password prompt. This allows more complex features like multiple-factor authentication and pre-authentication warnings and checks.
So your target probably supports keyboard-interactive and not password authentication.

Resources