<application-policy name="apollo">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapExtLoginModule"
flag="required">
<module-option name="debug">true</module-option>
<module-option name="java.naming.provider.url">ldap://localhost:389/</module-option>
<module-option name="java.naming.security.authentication">simple</module-option>
<module-option name="bindDN">CN=admin,CN=Users,CN=donLaptop,DC=don,DC=com</module-option>
<module-option name="bindCredential">secretpassword</module-option>
<module-option name="baseCtxDN">CN=Users,CN=donLaptop,DC=don,DC=com</module-option>
<!-- <module-option name="baseFilter">(sAMAccountName={0})</module-option> -->
<module-option name="baseFilter">(CN={0})</module-option>
<module-option name="rolesCtxDN">CN=Users,CN=donLaptop,DC=don,DC=com</module-option>
<module-option name="roleFilter">(member={1})</module-option>
<!-- module-option name="roleFilter">(sAMAccountName={0})</module-option -->
<module-option name="roleAttributeID">memberOf</module-option>
<module-option name="roleAttributeIsDN">true</module-option>
<module-option name="roleNameAttributeID">CN</module-option>
<!-- if a default role is needed to be applied to all accounts, it can be achieved by uncommenting the below -->
<!-- module-option name="defaultRole">esp_consumer</module-option -->
<module-option name="roleRecursion">2</module-option>
<module-option name="searchScope">SUBTREE_SCOPE</module-option>
<!-- An empty password is treated as an anonymous login by some ldap servers and this may not be a desirable feature.
Set this to false to reject empty passwords, true to have the ldap server validate the empty password. The default is true. -->
<module-option name="allowEmptyPasswords">false</module-option>
</login-module>
<!--
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name="usersProperties">props/apollo-users.properties</module-option>
<module-option name="rolesProperties">props/apollo-roles.properties</module-option>
</login-module>
-->
<!-- Need to include ClientLoginModule to propagate caller's subject and security context
Add this line to your login-config.xml to include the ClientLoginModule propogation -->
<login-module code="org.jboss.security.ClientLoginModule" flag="required">
<module-option name="restore-login-identity">true</module-option>
<module-option name="multi-threaded">true</module-option>
</login-module>
</authentication>
</application-policy>
</policy>
#
#############################################################################
#
# The nms-ldap.properties file is referenced by login-config.xml and is used
# by the NmsLdapLoginModule. This file controls whether LDAP access to a
# directory service is enabled for user passwords (and, optionally, user
# roles), and what parameter values are used.
#
# Contact your directory service administrator to determine the correct
# values to use in this file.
#
# This file is accessed before each attempt to sign in to the NNMi console,
# so its contents may be modified without restarting ovjboss.
#
# Whole line comments are allowed when start with a "#", but "#" characters
# at the end of a line are considered part of the value:
# paramName=paramValue # This string is part of paramName
#
# Any error messages from incorrect configuration of this file are logged to
#
#
# While testing changes to this file, be sure to use "File:Sign Out",
# instead of just closing the browser, to ensure you are fully signed
# out. Doing so prevents the browser from using cached credentials.
#
# For detailed information about configuring LDAP access to a directory
# service, see the HP Network Node Manager i-series Software Deployment and
# Migration Guide.
#
#############################################################################
#
#
# java.naming.provider.url:
#
# The URL for accessing the directory service.
#
# This parameter must be set to enable LDAP access to a directory service.
# If this parameter is not set in this file, LDAP queries are not
# attempted during user sign in.
#
# The value is in the form "ldap://ldap.myco.com" or
# "ldap://ldap.myco.com:636" (which is the same as
# "ldaps://ldap.myco.com:636").
#
# If a port is specified in the URL, the specified port overrides the
# default. If unspecified, port 389 is used for non-SSL connections, or
# port 636 is used for SSL connections (as defined by
# java.naming.security.protocol).
#
# To disable login attempts through LDAP, comment out this parameter.
#
# It is recommended that all User Accounts be deleted from NNMi after
# enabling this feature, and that all Principals be deleted from NNMi after
# disabling this feature. Doing so prevents accidental access through
# previously configured values.
#
#java.naming.provider.url=ldap://ldap.myco.com:389/
#
# java.naming.security.protocol:
#
# If this parameter is set to "ssl", NNMi uses the Secure Sockets Layer
# protocol for communications with the directory service.
#
# Enable SSL if you see an error in the jbossServer.log file that is
# similar to:
# javax.naming.AuthenticationNotSupportedException:
# [LDAP: error code 13 - confidentiality required]
#
# To enable SSL, import your company's trust store certificate into the
#
# as (for UNIX):
#
# /opt/OV/nonOV/jdk/nnm/bin/keytool -storepass ovpass -import \
# -file my_certificate_authority_cert.txt -alias 'nnmi_ldap' \
# -keystore /var/opt/OV/shared/nnm/certificates/nnm.truststore
#
# where my_certificate_authority_cert.txt is a file containing the
# certificate required by the directory service for SSL communication.
#
#java.naming.security.protocol=ssl
#
# bindDN:
# bindCredential:
#
# By default, the request to validate a username and password uses
# anonymous login. However some directory services (such as
# Active Directory Services) disallow anonymous access. Use this to
# provide credentials to the directory service.
# Note that as with any entry in this file, if you want to
# specify a backslash ('\'), it must be escaped as '\\'
#
#bindDN=MyDomain\\Some User Name
#bindCredential=someUserPassword
#############################################################################
#
# The distinguished name that is passed to the directory service for
# authenticating a user is the concatenation of the baseFilter value and the
# baseCtxDN value.
#
# For example, if baseFilter is set to "uid={0}", baseCtxDN is set to
# "ou=People,o=myco.com", and a user signs in to NNMi as "john.doe", then the
# string passed to the directory service is:
# uid=john.doe,ou=People,o=myco.com
#
#############################################################################
#
# baseCtxDN:
#
# Required. The user name search context, which is the fixed portion of the
# distinguished name for the user search.
#
# For an Active Directory server, this might be a value like:
# baseCtxDN=CN=Users,DC=mycompany,DC=com
#
baseCtxDN=ou=People,o=myco.com
#
# baseFilter:
#
# Required. The variable portion of the distinguished name for the user search.
#
# The baseFilter incorporates the user name entered for NNMi signin into the
# format needed for the distinguished name.
#
# The exact user name entered at the NNMi signin dialog is substituted for
# the expression "{0}" anywhere that it appears in the filter.
#
# A common value for baseFilter for OpenLDAP servers is:
# baseFilter=uid={0}
# A common value for baseFilter for Active Directory servers is:
# baseFilter=CN={0}
# or to use the Window NT 4.0 SAM-Account-Name:
# baseFilter=sAMAccountName={0}
#
baseFilter=uid={0}
#############################################################################
#
# You can verify the correctness of the above information in an LDAP client
# application, such as Microsoft Internet Explorer 7 or Mozilla Firefox 2.
#
# Enter an RFC 1959-compliant directory service URL with the above
# information, substituting a valid signin id. For instance, using the above
# values, and a signin of john.doe, you could test with a URL similar to:
# ldap://ldap.myco.com:389/uid=john.doe,ou=People,o=myco.com
# which is formed by concatenating the java.naming.provider.url, the
# baseFilter substituted with the signin name, a comma, and the baseCtxDN.
#
# If this URL times out, you probably have an incorrect directory service URL
# or port number.
#
# If you are using Active Directory (which does not allow anonymous binding),
# you can use an LDAP browsing program to verify your values are correct.
#
#############################################################################
#
# defaultRole:
#
# Optional. Use this parameter to specify a default role that applies to any
# directory service user who signs in to NNMi through LDAP. The value of this
# parameter applies regardless of where role mappings are stored (in the NNMi
# database or in the directory service). If a user is also a member of a group
# with an NNMi role attribute, NNMi uses the role with more privileges.
#
# Valid values are the NNMi roles: admin, level2, level1, guest, or client.
#
# If commented out, no default role is used, and the role mapping must
# be defined else the user will not be able to sign in to the NNMi console.
#
#defaultRole=guest
#############################################################################
#
# The remainder of the parameters in this file apply to customers who assign
# NNMi roles in the directory service.
#
# If you maintain NNMi role mapping in the NNMi database, stop here.
#
#############################################################################
#############################################################################
#
# After a user has been authenticated, NNMi queries the groups to which that
# user belongs to determine the NNMi roles that the user will have in NNMi.
# (When a user is assigned multiple roles, NNMi uses the role with more
# privileges.)
#
# The distinguished name that is passed to the directory service for
# identifying the groups to which a user belongs is the concatenation of the
# roleFilter value and the rolesCtxDN value.
#
# For example, if roleFilter is set to "member={1}", rolesCtxDN is set to
# "ou=Groups,o=myco.com", and the authenticated user distinguished name is
# "john.doe@myco.com", then the string passed to the directory service is:
# member=john.doe@myco.com,ou=Groups,o=myco.com
#
# All group distinguished names which have an attribute (uidAttributeID)
# that match the authenticated user will be used to assign the roles for
# the user. Any matching groups will use an attribute (roleAttributeID)
# to determine the role for the user.
#
#############################################################################
#
# rolesCtxDN:
#
# The group name search context, which is the fixed portion of the
# distinguished name for the user group search.
#
# This parameter must be set to enable directory service queries for NNMi
# role assignments through LDAP. If this parameter is not set in this file,
# LDAP queries for user roles are not attempted during user sign in.
#
# To disable directory service queries for NNMi role assignments through LDAP,
# comment out this parameter. The remaining values in this file will not be
# used.
#
# For a faster search, you can identify one or more directory service groups
# that contain NNMi roles. If the group names form a pattern, you can specify
# a wildcard. For example, if the directory service includes groups named
# "USERS-NNMi-administrators", "USERS-NNMi-level1Operators", and so forth,
# you could use a search context similar to:
# rolesCtxDN=cn=USERS-NNMi-*,ou=Groups,o=myco.com
# For an Active Directory server, this might be a value like:
# rolesCtxDN=CN=Users,DC=myco,DC=com
# which might be the same as baseCtxDN because Active Directory configurations
# sometime stores Groups and Users at the same level.
#
#rolesCtxDN=ou=Groups,o=myco.com
#
# roleFilter:
#
# The variable portion of the distinguished name for the user group search.
#
# The user name entered for signin is substituted for the expression {0}
# anywhere that it appears in the filter.
#
# The distinguished name of the authenticated user is substituted for the
# expression {1} anywhere that it appears in the filter.
#
# An example role filter that matches on the (short) user name entered for
# signin is: member={0}
#
# An example role filter that matches on the authenticated (full) user
# distinguished name is: member={1}
#
roleFilter=member={1}
#############################################################################
#
# You can verify the correctness of the group query by passing a URL
# similar to the following, and entering it into a web browser, unless
# your directory server does not allow anonymous authentication (as
# is the default case for Active Directory). An example is:
# ldap://ldap.myco.com:389/ou=Groups,o=myco.com??sub?(cn=SOME-PATTERN-*)
# which is formed by concatenating the java.naming.provider.url, the
# baseCtxDN, and an optional search context limiter.
#
# If you are using Active Directory, you can use an LDAP browsing program
# to verify your values are correct.
#
#############################################################################
#
# roleAttributeIsDN:
# roleAttributeID:
# roleNameAttributeID:
#
# roleAttributeIsDN is a flag indicating whether the user's role attribute
# contains the fully distinguished name of a role object, or the users's role
# attribute contains the role name.
# In certain directory schemas (for example, Microsoft Active Directory),
# role (group) attributes in the user object are stored as distinguished names
# to role objects instead of as simple names, in which case, this property
# should be set to roleAttributeIsDN=true
# In non-Active Directory cases, false is the correct value
# of roleAttributeIsDN.
#
#
# If roleAttributeIsDN=false, the role name is taken directly from the
# value of the user's role attribute (roleAttributeID).
# For non-Active Directory servers, it is recommended that a group be created
# with an additional attribute called "roleName" that contains a value of
# admin (for Administrator role), level2 (for Level 2 Operator role),
# level1 (for Level 1 Operator role), guest (for Guest role), or
# client (if required when using the NNMi SDK and integrations). In such
# a case, you would use
# roleAttributeID=roleName
# This attribute is the name of the attribute in the group, which is
# set to a different value for each NNMi role-defining group.
#
#
# If roleAttributeIsDN=true, the following definitions apply.
# roleAttributeID is the name of the attribute in the group that stores the NNMi role value that
# applies to the members of the directory server group. For Active Directory,
# this is usually:
# roleAttributeID=memberOf
# The role attribute (roleNameAttributeID) represents
# the distinguished name of a role object, and the role name is taken from the
# value of the "roleAttributeID" attribute of the corresponding group
# specified by roleNameAttributeID.
# This is also useful if you are unable to change the schema to add an attribute
# (such as roleName), and just want the name of the group to be the role. In
# that case, you could use roleNameAttributeID=name or
# roleNameAttributeID=CN to actually use the name of the group as the nnmi
# role. This implies that you created groups specifically called admin, level2,
# level1, guest or client.
#
# In some Active Directory implementations you cannot create a new attribute
# to store the NNMi role. Active Directory groups have an "info" attribute
# you can change (often named "Notes" in the Active Directory
# configuration). In this case you would set the "info" attribute
# in your Level 2 Group in Active Directory to "level2", and use
# roleNameAttributeID=info
#
roleAttributeIsDN=false
roleAttributeID=nnmiRole
#
# Active Directory instead uses roleAttributeIsDN=true
# In this case, the actual attribute to get the role is two hops
# away, using roleAttributeID to find the DN which actually contains
# the attribute.
#
#roleAttributeIsDN=true
#roleAttributeID=memberOf
#roleNameAttributeID=info
#############################################################################
#
# The following two attributes are used to enable Incident Assignment
#
#############################################################################
#
# userRoleFilterList:
#
# A semicolon-separated list of NNMi roles whose associated users can be
# assigned incidents in the NNMi console. The roles in this list apply only
# to directory service user names authenticated through LDAP.
# If this value is incorrect, sign in will find the correct user Role,
# but selecting an Incident and picking Actions -> Assign Incident... will
# bring up a dialog with no users.
#
# Valid values are the NNMi roles: admin, level2, level1, guest, or client.
#
userRoleFilterList=admin;level2;level1
#
# uidAttributeID:
#
# The name of the attribute in the group that stores the directory service user ID.
# The value of this attribute is used to locate the user's role. It is
# usually the attribute portion of roleFilter. This attribute is used for
# looking up the list of users for Incident assignment.
# If this value is incorrect, sign in will find the correct user Role,
# but selecting an Incident and picking Actions -> Assign Incident... will
# bring up a dialog with no users.
#
uidAttributeID=member
#############################################################################
#
# The following only needs to be modified if you are finding timeouts
# when accessing a distant directory server.
#
#############################################################################
#
# searchTimeLimit
#
# If you have a slow responding directory service, you may get errors like:
# javax.naming.TimeLimitExceededException: [LDAP: error code 3 - Timelimit Exceeded]
# in this case, you can increase the searchTimeLimit. This value is
# in milliseconds. The default value is 10000 (10 seconds)
#
#searchTimeLimit=10000
No comments:
Post a Comment