Authorization Commands in MQ #windows - ibm-mq

Question

Below commands done for Authorization in Unix + MQ9. Want to review(is this a correct approach or not?) as well as How below commands can be achieved in Windows server?
setmqaut -m TLSTEST.QM -t qmgr -p clientadmin +connect +dsp +inq
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n '**' +put +get +browse +dsp +inq
runmqsc TLSTEST.QM
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
ALTER QMGR CHLAUTH(DISABLED)
REFRESH SECURITY TYPE(CONNAUTH)
Update on 29-Mar-2017
is setmqaut can be used as only to required is fine as below ,instead of '**'?
setmqaut -m TLSTEST.QM -t qmgr -p clientadmin +connect +dsp +inq
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n RECEIVE +put +get +browse +dsp +inq
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n SEND +put +get +browse +dsp +inq
below commands are required for me , because my jms-client will not pass user details on connection request.Is good approach to pass as below in client code or externalize these values?
MQEnvironment.userID = "mqm";
MQEnvironment.password = "password";
runmqsc TLSTEST.QM
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
ALTER QMGR CHLAUTH(DISABLED)
REFRESH SECURITY TYPE(CONNAUTH)

Answer 1

The commands you provided in your question would work equally as well in windows as they do in Unix.
NOTE The commands you propose turn off security which is not a good thing to do and also authorized the user "clientadmin" to all queues on the queue manager including SYSTEM* queues which allows that user to leverage MQ administrative authority.
Commands from your 29-Mar-2017 update look fine for providing specific permissions to queues SEND and RECEIVE.
In my opinion it would be a good approach to externalize the values for userID and password so that you do not need to recompile things if these change in the future.
Having an application connect as mqm is not a good approach since mqm has full administrative authority.
Setting CHLAUTH(DISABLED) does not prevent password checking it just turns off the normal out of the box CHLAUTH rules which prevent MQ admins from connecting to SVRCONN channels, as well as preventing usage of SYSTEM.* channels.
Setting CHCKCLNT(OPTIONAL) from the default of CHCKCLNT(REQDADM) configures MQ to check that a password is valid only if a password is supplied to MQ.
The default value CHCKCLNT(REQDADM) is the same as CHCKCLNT(OPTIONAL) with the additional requirement that that accounts with MQ admin authority are required to supply a valid password. Accounts without MQ admin authority are not required to present a valid password but if a password is supplied it must be valid.
If your configuration only works with CHCKCLNT(OPTIONAL) it would indicate that you are connecting as an account that has MQ admin authority.
There is a security issue with setting MQ to not enforce that a valid password is sent unless you use SSLCIPH and SSLPEER to restrict a SVRCONN to allow only specific client certs to connect and you make sure all other channels are locked down. The default CHLAUTH rules lock down all channels by not allowing users with MQ admin authority to connect, and they block connections to all SYSTEM* channels.
Setting SSLCAUTH(OPTIONAL) configures MQ to not require that the client have a certificate, if the client does have a certificate MQ will validate it is trusted, and if you have a SSLPEER set will make sure the client certificate DN value matches.
SSLCAUTH(REQUIRED) configures MQ to require that the client have a cert. You would also want to pair this with the channels SSLPEER setting to ensure the cert is the one that you expect not just a cert that is trusted by the queue manager, you also want to set the MCAUSER to a low privileged user.
Setting CHLAUTH(DISABLED) likely is making the SYSTEM.* channels insecure.
If you have no other mitigating controls the configuration presented is insecure.