mq authentication info

Overview

This resource allows you to manage MQ authorization Information Objects.

Here is an example on how you should use this:

mq_authentication_info { 'QM1/CRLLDAP/MY_LDAP':
  ensure   => 'present',
}

Attributes

adoptctx

Whether to use the presented credentials as the context for this application. This means that they are used for authorization checks, shown on administrative displays, and appear in messages.

• YES The user ID presented in the MQCSP structure, which has been successfully validated by password, is adopted as the context to use for this application. Therefore, this user ID will be the credentials checked for authorization to use IBM MQ resources. If the user ID presented is an LDAP user ID, and authorization checks are done using operating system user IDs, the SHORTUSR associated with the user entry in LDAP will be adopted as the credentials for authorization checks to be done against.
• NO Authentication will be performed on the user ID and password presented in the MQCSP structure, but then the credentials will not be adopted for further use. Authorization will be performed using the user ID the application is running under. This attribute is only valid for an AUTHTYPE of IDPWOS and IDPWLDAP.

Valid values are YES, NO.

Back to overview of mq_authentication_info

authenmd

Authentication method. Whether to use the operating system or Pluggable Authentication Method (PAM) to authenticate user passwords.

• OS Use the traditional UNIX password verification method.
• PAM Use the PAM to authenticate the user password.

You can set the PAM value only on UNIX and Linux. Changes to this attribute are effective only after you run the REFRESH SECURITY TYPE(CONNAUTH) command. This attribute is valid only for an AUTHTYPE of IDPWOS.

Valid values are OS, PAM.

Back to overview of mq_authentication_info

authentication_type

The authentication type.

This is a puppet parameter and not a managed property. Therefor it is only used during creation of the resource. Changes to this parameter in your manifest, do NOT result in modifications on the system.

Valid values are CRLLDAP, OCSP, IDPWOS, IDPWLDAP.

Back to overview of mq_authentication_info

authormd

Authorization Method.

• OS Use operating system groups to determine permissions associated with a user. This is how IBM MQ has previously worked, and is the default value.
• SEARCHGRP A group entry in the LDAP repository contains an attribute listing all the users belonging to that group. Membership is indicated by the attribute defined in FINDGRP. This value is typically member or uniqueMember.
• SEARCHUSR A user entry in the LDAP repository contains an attribute listing all the groups to which the specified user belongs. The attribute to query is defined by the FINDGRP value, typically memberOf. Many LDAP servers use an attribute of the group object to determine group membership and you should, therefore, set this value to SEARCHGRP. Microsoft Active Directory typically stores group memberships as a user attribute. The IBM Tivoli Directory Server supports both methods. In general, retrieving memberships through a user attribute will be faster than searching for groups that list the user as a member.

Valid values are OS, SEARCHGRP, SEARCHUSR.

Back to overview of mq_authentication_info

basedng

Base DN for groups. In order to be able to find group names, this parameter must be set with the base DN to search for groups in the LDAP server.

Back to overview of mq_authentication_info

basednu

In order to be able to find the short user name attribute (see SHORTUSR ) this parameter must be set with the base DN to search for users within the LDAP server. This attribute is valid only for an AUTHTYPE of IDPWLDAP.

Back to overview of mq_authentication_info

chckclnt

This attribute determines the authentication requirements for client applications, and is valid only for an AUTHTYPE of IDPWOS or IDPWLDAP. The possible values are:

• NONE No user ID and password checks are made. If any user ID or password is supplied by a client application, the credentials are ignored.
• OPTIONAL Client applications are not required to provide a user ID and password. Any applications that do provide a user ID and password in the MQCSP structure have them authenticated by the queue manager against the password store indicated by the AUTHTYPE. The connection is only allowed to continue if the user ID and password are valid. This option might be useful during migration, for example.
• REQUIRED All client applications must provide a user ID and password in the MQCSP structure. This user ID and password is authenticated by the queue manager against the password store indicated by the AUTHTYPE. The connection will only be allowed to continue if the user ID and password are valid.
• REQDADM All client applications using a privileged user ID must provide a user ID and password in the MQCSP structure. Any locally bound applications using a non-privileged user ID are not required to provide a user ID and password and are treated as with the OPTIONAL setting. Any provided user ID and password are authenticated by the queue manager against the password store indicated by the AUTHTYPE. The connection is only allowed to continue if the user ID and password are valid.

Note The REQDADM value for the CHCKCLNT attribute is irrelevant if the authentication type is LDAP. This is because there is no concept of privileged user ID when using LDAP user accounts. LDAP user accounts and groups must be assigned permission explicitly.

Valid values are NONE, OPTIONAL, REQUIRED, REQDADM.

Back to overview of mq_authentication_info

chcklocl

This attribute determines the authentication requirements for locally bound applications, and is valid only for an AUTHTYPE of IDPWOS or IDPWLDAP. [MQ Appliance]For information about use of this attribute on IBM MQ Appliance, see Control commands on the IBM MQ Appliance in the IBM MQ Appliance documentation. The possible values are:

• NONE No user ID and password checks are made. If any user ID or password is supplied by a locally bound application, the credentials are ignored.
• OPTIONAL Locally bound applications are not required to provide a user ID and password. Any applications that do provide a user ID and password in the MQCSP structure have them authenticated by the queue manager against the password store indicated by the AUTHTYPE. The connection is only allowed to continue if the user ID and password are valid. This option might be useful during migration, for example.
• REQUIRED All locally bound applications must provide a user ID and password in the MQCSP structure. This user ID and password will be authenticated by the queue manager against the password store indicated by the AUTHTYPE. The connection will only be allowed to continue if the user ID and password are valid. [z/OS]If your user ID has UPDATE access to the BATCH profile in the MQCONN class, you can treat CHCKLOCL(REQUIRED) as if it is CHCKLOCL(OPTIONAL). That is, you do not have to supply a password, but if you do, the password must be the correct one. See Using CHCKLOCL on locally bound applications.
• REQDADM All locally bound applications using a privileged user ID must provide a user ID and password in the MQCSP structure. Any locally bound applications using a non-privileged user ID are not required to provide a user ID and password and are treated as with the OPTIONAL setting. Any provided user ID and password will be authenticated by the queue manager against the password store indicated by the AUTHTYPE. The connection will only be allowed to continue if the user ID and password are valid.

Valid values are NONE, OPTIONAL, REQUIRED, REQDADM.

Back to overview of mq_authentication_info

classgrp

The LDAP object class used for group records in the LDAP repository. If the value is blank, groupOfNames is used. Other commonly used values include groupOfUniqueNames or group.

Back to overview of mq_authentication_info

classusr

The LDAP object class used for user records in the LDAP repository. If blank, the value defaults to inetOrgPerson, which is generally the value needed. For Microsoft Active Directory, the value you require is often user. This attribute is valid only for an AUTHTYPE of IDPWLDAP.

Back to overview of mq_authentication_info

conname

The host name, IPv4 dotted decimal address, or IPv6 hexadecimal notation of the host on which the LDAP server is running, with an optional port number. This parameter is valid only for AUTHTYPE(CRLLDAP), when it is mandatory. If you specify the connection name as an IPv6 address, only systems with an IPv6 stack are able to resolve this address. If the AUTHINFO object is part of the CRL namelist of the queue manager, ensure that any clients using the client channel table generated by the queue manager can resolve the connection name. On z/OS, if a CONNAME is to resolve to an IPv6 network address, a level of z/OS that supports IPv6 for connection to an LDAP server is required. The syntax for CONNAME is the same as for channels

Back to overview of mq_authentication_info

descr

Plain-text comment. It provides descriptive information about the authentication information object when an operator issues the DISPLAY AUTHINFO command (see DISPLAY AUTHINFO ). It must contain only displayable characters. The maximum length is 64 characters. In a DBCS installation, it can contain DBCS characters (subject to a maximum length of 64 bytes).

Back to overview of mq_authentication_info

disable_corrective_change

Disable the modification of a resource when Puppet decides it is a corrective change.

(requires easy_type V2.11.0 or higher)

When using a Puppet Server, Puppet knows about adaptive and corrective changes. A corrective change is when Puppet notices that the resource has changed, but the catalog has not changed. This can occur for example, when a user, by accident or willingly, changed something on the system that Puppet is managing. The normal Puppet process then repairs this and puts the resource back in the state as defined in the catalog. This process is precisely what you want most of the time, but not always. This can sometimes also occur when a hardware or network error occurs. Then Puppet cannot correctly determine the current state of the system and thinks the resource is changed, while in fact, it is not. Letting Puppet recreate remove or change the resource in these cases, is NOT wat you want.

Using the disable_corrective_change parameter, you can disable corrective changes on the current resource.

Here is an example of this:

crucial_resource {'be_carefull':
  ...
  disable_corrective_change => true,
  ...
}

When a corrective ensure does happen on the resource Puppet will not modify the resource and signal an error:

    Error: Corrective change present requested by catalog, but disabled by parameter disable_corrective_change
    Error: /Stage[main]/Main/Crucial_resource[be_carefull]/parameter: change from '10' to '20' failed: Corrective change present requested by catalog, but disabled by parameter disable_corrective_change. (corrective)

Back to overview of mq_authentication_info

disable_corrective_ensure

Disable the creation or removal of a resource when Puppet decides is a corrective change.

(requires easy_type V2.11.0 or higher)

When using a Puppet Server, Puppet knows about adaptive and corrective changes. A corrective change is when Puppet notices that the resource has changed, but the catalog has not changed. This can occur for example, when a user, by accident or willingly, changed something on the system that Puppet is managing. The normal Puppet process then repairs this and puts the resource back in the state as defined in the catalog. This process is precisely what you want most of the time, but not always. This can sometimes also occur when a hardware or network error occurs. Then Puppet cannot correctly determine the current state of the system and thinks the resource is changed, while in fact, it is not. Letting Puppet recreate remove or change the resource in these cases, is NOT wat you want.

Using the disable_corrective_ensure parameter, you can disable corrective ensure present or ensure absent actions on the current resource.

Here is an example of this:

crucial_resource {'be_carefull':
  ensure                    => 'present',
  ...
  disable_corrective_ensure => true,
  ...
}

When a corrective ensure does happen on the resource Puppet will not create or remove the resource and signal an error:

    Error: Corrective ensure present requested by catalog, but disabled by parameter disable_corrective_ensure.
    Error: /Stage[main]/Main/Crucial_resource[be_carefull]/ensure: change from 'absent' to 'present' failed: Corrective ensure present requested by catalog, but disabled by parameter disable_corrective_ensure. (corrective)

Back to overview of mq_authentication_info

ensure

The basic property that the resource should be in.

Valid values are present, absent.

Back to overview of mq_authentication_info

faildlay

When a user ID and password are provided for connection authentication, and the authentication fails due to the user ID or password being incorrect, this is the delay, in seconds, before the failure is returned to the application. This can aid in avoiding busy loops from an application that simply retries, continuously, after receiving a failure. The value must be in the range 0 - 60 seconds. The default value is 1. This attribute is only valid for an AUTHTYPE of IDPWOS and IDPWLDAP.

Back to overview of mq_authentication_info

findgrp

Name of the attribute used within an LDAP entry to determine group membership. When AUTHORMD = SEARCHGRP, this attribute is typically set to member or uniqueMember. When AUTHORMD = SEARCHUSR, this attribute is typically set to memberOf. If left blank, the queue manager uses member or memberOf depending on the setting of AUTHORMD.

Back to overview of mq_authentication_info

grpfield

LDAP attribute that represents a simple name for the group. If the value is blank, commands like setmqaut must use a qualified name for the group. The value can either be a full DN, or a single attribute.

Back to overview of mq_authentication_info

ldappwd

The password associated with the Distinguished Name of the user who is accessing the LDAP server. Its maximum size is 32 characters. This parameter is valid only for AUTHTYPE(CRLLDAP). On z/OS, the LDAPPWD used for accessing the LDAP server might not be the one defined in the AUTHINFO object. If more than one AUTHINFO object is placed in the namelist referred to by the QMGR parameter SSLCRLNL, the LDAPPWD in the first AUTHINFO object is used for accessing all LDAP Servers. This attribute is valid only for an AUTHTYPE of CRLLDAP and IDPWLDAP.

This is a puppet parameter and not a managed property. Therefor it is only used during creation of the resource. Changes to this parameter in your manifest, do NOT result in modifications on the system.

Back to overview of mq_authentication_info

ldapuser

he Distinguished Name of the user who is accessing the LDAP server. (See the SSLPEER parameter for more information about distinguished names.) This parameter is valid only for AUTHTYPE(CRLLDAP). The maximum size for the user name is 1024 characters on IBM i, UNIX, Linux, and Windows, and 256 characters on z/OS. On z/OS, the LDAPUSER used for accessing the LDAP Server might not be the one defined in the AUTHINFO object. If more than one AUTHINFO object is placed in the namelist referred to by the QMGR parameter SSLCRLNL, the LDAPUSER in the first AUTHINFO object is used for accessing all LDAP Servers. On IBM i, UNIX, Linux, and Windows, the maximum accepted line length is defined to be BUFSIZ, which can be found in stdio.h. This attribute is valid only for an AUTHTYPE of CRLLDAP and IDPWLDAP.

Back to overview of mq_authentication_info

like

The name of an authentication information object, with parameters that are used to model this definition. [z/OS]On z/OS, the queue manager searches for an object with the name you specify and a disposition of QMGR or COPY. The disposition of the LIKE object is not copied to the object you are defining.

Back to overview of mq_authentication_info

name

The full name of the object which security you want to manage. The full name constists of the name of the Queue manager, a slash and then the name of the object. Here is an example:

QMGR1/MY.FIRST.CHANNEL

This is a puppet parameter and not a managed property. Therefor it is only used during creation of the resource. Changes to this parameter in your manifest, do NOT result in modifications on the system.

Back to overview of mq_authentication_info

nestgrp

Group nesting.

• NO Only the initially discovered groups are considered for authorization.
• YES The group list is searched recursively to enumerate all the groups to which a user belongs.

Valid values are YES, NO.

Back to overview of mq_authentication_info

object_name

The object name.

This is a puppet parameter and not a managed property. Therefor it is only used during creation of the resource. Changes to this parameter in your manifest, do NOT result in modifications on the system.

Back to overview of mq_authentication_info

ocspurl

The URL of the OCSP responder used to check for certificate revocation. This value must be an HTTP URL containing the host name and port number of the OCSP responder. If the OCSP responder is using port 80, which is the default for HTTP, then the port number can be omitted. HTTP URLs are defined in RFC 1738. This field is case sensitive. It must start with the string http:// in lowercase. The rest of the URL might be case sensitive, depending on the OCSP server implementation. To preserve case, use single quotation marks to specify the OCSPURL parameter value, for example: OCSPURL (‘http://ocsp.example.ibm.com’) This parameter is applicable only for AUTHTYPE(OCSP), when it is mandatory.

Back to overview of mq_authentication_info

provider

The specific backend to use for this mq_authentication_info resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform.Available providers are:

simple

Manage MQ AUthentication Information Objects

Back to overview of mq_authentication_info

qmgr

The queue manager.

This is a puppet parameter and not a managed property. Therefor it is only used during creation of the resource. Changes to this parameter in your manifest, do NOT result in modifications on the system.

Back to overview of mq_authentication_info

seccomm

• YES Connectivity to the LDAP server is made securely using TLS. The certificate used is the default certificate for the queue manager, named in CERTLABL on the queue manager object, or if that is blank, the one described in Digital certificate labels, understanding the requirements. The certificate is located in the key repository specified in SSLKEYR on the queue manager object. A cipherspec will be negotiated that is supported by both IBM MQ and the LDAP server. If the queue manager is configured to use SSLFIPS(YES) or SUITEB cipher specs, then this is taken account of in the connection to the LDAP server as well.
• ANON Connectivity to the LDAP server is made securely using TLS just as for SECCOMM(YES) with one difference. No certificate is sent to the LDAP server; the connection will be made anonymously. To use this setting, ensure that the key repository specified in SSLKEYR, on the queue manager object, does not contain a certificate marked as the default.
• NO Connectivity to the LDAP server does not use TLS.

This attribute is valid only for an AUTHTYPE of IDPWLDAP.

Valid values are YES, ANON, NO.

Back to overview of mq_authentication_info

shortusr

A field in the user record to be used as a short user name in IBM MQ. This field must contain values of 12 characters or less. This short user name is used for the following purposes: If LDAP authentication is enabled, but LDAP authorization is not enabled, this is used as an operating system user ID for authorization checks. In this case, the attribute must represent an operating system user ID. If LDAP authentication and authorization are both enabled, this is used as the user ID carried with the message in order for the LDAP user name to be rediscovered when the user ID inside the message needs to be used. For example, on another queue manager, or when writing report messages. In this case, the attribute does not need to represent an operating system user ID, but must be a unique string. An employee serial number is an example of a good attribute for this purpose. This attribute is valid only for an AUTHTYPE of IDPWLDAP and is mandatory.

Back to overview of mq_authentication_info

usrfield

If the user ID provided by an application for authentication does not contain a qualifier for the field in the LDAP user record, that is, it does not contain an ‘ = ‘ sign, this attribute identifies the field in the LDAP user record that is used to interpret the provided user ID. This field can be blank. If this is the case, any unqualified user IDs use the SHORTUSR parameter to interpret the provided user ID. The contents of this field will be concatenated with an ‘ = ‘ sign, together with the value provided by the application, to form the full user ID to be located in an LDAP user record. For example, the application provides a user of fred and this field has the value cn, then the LDAP repository will be searched for cn=fred. This attribute is valid only for an AUTHTYPE of IDPWLDAP.

Back to overview of mq_authentication_info