AmazonMQ ActiveMQ issue with permissions too strict - activemq

I have a setup of AmazonMQ (ActiveMQ 5.17.1) with a user defined like this in my terraform:
user {
username = "myUser"
password = "somethingSecret"
console_access = false
}
and the ActiveMQ configuration without any authorizationMap: my client is able to connect without issue.
Now I want to set up the authorizationMap for some other users and give the user myUser admin rights on all queues and topics.
Here is how looks my authorizationMap:
<authorizationPlugin>
<map>
<authorizationMap>
<authorizationEntries>
<authorizationEntry queue="SYS1.IN.>" read="system1"/>
<authorizationEntry queue="SYS2.IN>" read="system2"/>
<authorizationEntry queue="SYS2.OUT>" write="system2"/>
<!-- few other queues / permissions -->
<!-- taken from https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/child-element-details.html#authorizationEntry -->
<authorizationEntry admin="admins,activemq-webconsole" read="admins,users,activemq-webconsole" write="admins,activemq-webconsole" queue=">"/>
<authorizationEntry admin="admins,activemq-webconsole" read="admins,users,activemq-webconsole" write="admins,activemq-webconsole" topic=">"/>
</authorizationEntries>
</authorizationMap>
</map>
</authorizationPlugin>
and I also added the myUSer to the admin group in terraform:
user {
username = "myUser"
password = "somethingSecret"
groups = ["admins"]
}
But with this setup I see in the AWS logs (and on the client side as well) an error saying something like:
... User myUser doesn't have permission to write in topic `ActiveMQ.Advisory.Connection` ...
I tried to add the following entry in the authorizationMap (keeping the existing one above):
<authorizationEntry topic="ActiveMQ.Advisory.>" read="admins,activemq-webconsole" write="admins,activemq-webconsole" admin="admins,activemq-webconsole"/>
But the error is still the same.
Note that when I tried to send a message in a queue from the console (with another user where console_access = true) an error occurs but I can create new queues.
Note that I force a reboot of the broker between each configuration change but the above error remains.

I found two issues with my terraform file:
First I had to add an authentication_strtategy:
authentication_strategy = "simple"
but this alone was still not working.
After from the Console I saw that my broker was not referring the latest configuration.
Then secondly, I had to explicitly add the revision line in my configuration like this:
configuration {
id = aws_mq_configuration.conf-amq-area51-dev.id
revision = aws_mq_configuration.conf-amq-area51-dev.latest_revision
}
to explicitly refer the latest version as I made the (false) assumption that not referring the revision would implicitly take the latest one.
After these two changes I am able to use my user properly and the console admin is also working properly.
Another important point which was also missing in my initial configuration: the group assigned to each user. If I want to assign authorization like the one in the question:
<authorizationEntry queue="SYS1.IN.>" read="system1"/>
<authorizationEntry queue="SYS2.IN>" read="system2"/>
<authorizationEntry queue="SYS2.OUT>" write="system2"/>
The system1 and system2 represents groups and not user because in ActiveMQ the authorizationEntry is always referring to a group and not individual user. The workaround is to name (and assign) the group with the same name as the user (a bit like in Linux).
In Terraform, you can declare them like this:
user {
username = "system1"
password = "somethingSecretPa$$01"
console_access = false
groups = ["system1"]
}
user {
username = "system2"
password = "somethingSecretPa$$02"
console_access = false
groups = ["system2"]
}

Related

How to enable Streamset Mutitenancy using LDAP Authentication

I am using Streamset Data Collector version 3.19.1, currently am trying to integrate Streamset with LDAP server for authentication, I am successful with the integration however we are facing difficulties in configuring the roles and groups like the way it is in File based.
i.e in file based you have three things to configure a)user b)role c) group
<user name>: MD5:<md5-text>, user, <role> [, <additional role>, <additional role>...] [, group:<group>, group:<additional group>...]
if you look at above syntax, there is user name which can be user defined, then there is user which is fixed value, then we have role it can be one of (Admin,Manager,Creator and guest) and last we have group which us again user defined this can be used for Multitenancy.
however now comparing to LDAP configuration provided by streamset we have only following attributes to configure.
<ldap group>:<SDC role>,<additional SDC role>,<additional SDC role>);<ldap group>:<SDC role>,<additional SDC role>...
from above syntax we can see can be configured which is user defined and SDC role which can be one of the following(Admin,Manager,Creator and guest) with this the configuration will look like
DEV:creator;OPS:manager;
how can I configure LDAP rule mapping for group and role, currently i can only map for role in LDAP, requesting anyone to help here, i tried all my best to resolve unfortunately couldnt find any solution.
You can use the same configuration for groups as well. Following from my environment.
http.authentication.ldap.role.mapping=operators:admin;
To get the groups ldap-login-conf needs to be configured like following:-
roleBaseDn="OU=operations,OU=test_groups,OU=groups,OU=sdc,DC=example,DC=COM"
roleNameAttribute="cn"
roleMemberAttribute="member"
roleObjectClass="group"
roleFilter="member={dn}";

How to unlock user on ApacheDS

I setup an ApacheDS with default password-policy enabled. For testing proposes I locked a simple User (objectClass=Person extended with some custom User-objectClass) by entering the wrong credentials a number of times. As I expected the user was locked (error msg: user was permanently locked).
The question now is: How to unlock the user again? Is there a better way then just deleting and adding again?
I tried the same with an extended user (objectClass=pwdPolicy) but no pwd* attributes were added when the user was locked.
More recently, I encountered the same problem at work. But, it seems that there is no answer on Internet. Finally,I found the answer by viewing this document:
Password Policy for LDAP Directories draft-behera-ldap-password-policy
At section 5.3.3: pwdAccountLockedTime
This attribute holds the time that the user's account was locked. A
locked account means that the password may no longer be used to
authenticate. A 000001010000Z value means that the account has been
locked permanently, and that only a password administrator can unlock
the account.
At section 5.2.12: pwdLockoutDuration
This attribute holds the number of seconds that the password cannot
be used to authenticate due to too many failed bind attempts. If
this attribute is not present, or if the value is 0 the password
cannot be used to authenticate until reset by a password
administrator.
Through above two section, we can assume that we should connect to ApacheDS server with administrator(by default: uid=admin,ou=system, password=secret ), and delete the user's userPassword attribute. By this way,the permanently locked user can be unlock.
I practiced this sulotion and it works well.
I suggest you should set value for pwdLockoutDuration attribute, in this case the user can not been permanently locked.
For more infomation:
ApacheDS password Policy
Use ApacheDS Studio and log in as admin, find the user, right-click and choose "Fetch->Fetch operational attributes". Now pwdAccountLockedTime is visible and you can delete it to unlocks the user
The answer by Mister's is perfect to unlock an account and if you want to set the pwdLockoutDuration for a single user (assuming the user has implemnted the objectClass pwdPolicy.
There is also a global config file found in:
ou=config
* ads-directoryServiceId=<default>
* ou=interceptors
* ads-interceptorId=authenticationInterceptor
* ou=passwordPolicies
Here we can set the default password policy:
As mine is just a test-server, I have completely disabled lockout via setting the ads-pwdlockout to FALSE. For more on configuring password policy read the official docs.
For reference, this is how you enable this on the server via java:
AuthenticationInterceptor authenticationInterceptor = new AuthenticationInterceptor();
PasswordPolicyConfiguration config = new PasswordPolicyConfiguration();
config.setPwdLockout(true);
authenticationInterceptor.setPwdPolicies(config);
Client methods can then be written, to enable/disable specific accounts, similar to:
public void disableUser(String dn) throws LdapException, UnsupportedEncodingException
{
Modification disablePassword = new DefaultModification(
ModificationOperation.REPLACE_ATTRIBUTE, "pwdAccountLockedTime","000001010000Z" );
connection.modify(dn,disablePassword);
}
public void enableUser(String dn) throws LdapException, UnsupportedEncodingException
{
Modification disablePassword = new DefaultModification(ModificationOperation.REMOVE_ATTRIBUTE, "pwdAccountLockedTime");
connection.modify(dn,disablePassword);
}

XMPP JID seems like always null

I use XMPP to build a chat application. While attempting to log in, I see that my JID instance is always null. I thus can connect the server but I cannot properly authenticate.
self.xmppStream.myJID = [XMPPJID jidWithString:#"efeuser"];
NSLog(#"%#",self.xmppStream.myJID.user);
It logs myJID as null.
I also tried to create a new user on Openfire with register packet, but the user JID is also null.
<iq xmlns="jabber:client" type="error" to="bowerchat.com/3df1adfc">
<query xmlns="jabber:iq:register">
<username/>
<password>efe1414</password>
</query>
<error code="500" type="wait">
<internal-server-error xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</error>
</iq>
JIDs can be of two forms:
user#example.com
example.com
If they include an #, then the part before the # is the userpart. But the userpart may also be left out, as it is in the second example. This is usually used to address the host directly.
self.xmppStream.myJID = [XMPPJID jidWithString:#"efeuser"];
This creates a new JID efeuser with no userpart. This means:
NSLog(#"%#",self.xmppStream.myJID.user);
Prints (null) correctly, as there is no userpart.

Gerrit + LDAP = LDAP authentication unavailable Tuleap

I have been trying to setup gerrit to work with LDAP authentication. I read documentation numerous time some link do not work to the examples documentation pulled from tuleap on subject comes up with different solutions and explanations I have found three different configurations for ldap.inc from tuleap this is very confusing lacking explanation too.
So i am stuck with this problem. I have spent hours reading and trying to sort this out. Can someone tell me what am I doing wrong? here is my
ldap.inc
<?php
// LDAP server(s) to query for more information on Tuleap users and
// for authentication.
// You may use a comma-separated list if there are several servers available
// (leave blank to disable LDAP lookup).
// To specify secure LDAP servers, use 'ldaps://servername'
$sys_ldap_server = 'techhub.lt';
// To enable LDAP information on Tuleap users, also define the DN
// (distinguised name) to use in LDAP queries.
// The ldap filter is the filter to use to query the LDAP directory
// (%name% are substituted with the value from the user table)
$sys_ldap_dn = 'dc=techhub,dc=lt';
// For LDAP systems that do not accept anonymous binding, define here
// a valid DN and password:
$sys_ldap_bind_dn = "cn=admin,dc=techhub,dc=lt";
$sys_ldap_bind_passwd = "pass";
// LDAP authentication:
// Tuleap only supports authentication with a attempt to bind with LDAP server
// with a DN and a password.
// As the DN is usually long (eduid=1234,ou=people,dc=tuleap,dc=com) people
// usually authenticate themself with a login. So we need to first look
// for the DN that correspond to the given login and once found attempt to bind
// with the given password.
// In order to autenticate successfully users you need to properly
// User login (authentication 1st step)
$sys_ldap_uid = 'uid';
// User unique identifier. It's probably not the uid (or login) because it
// may change. This is a value that never change whatever happens to the
// user (even after deletion). It correspond to ldap_id field in user table
// in database.
// (authentication 2st step)
$sys_ldap_eduid = 'eduid';
// User common name
$sys_ldap_cn = 'cn';
// User email address
$sys_ldap_mail = 'mail';
// Specific DN to look for people
// You may use more than one DN separated by ; if you want to use several branches.
// Example : 'ou=People, dc=st, dc=com ; ou=Extranet, dc=st, dc=com'
$sys_ldap_people_dn = 'ou=people,dc=techhub,dc=lt';
// Filter used to look for user. It should cover a wide selection of
// fields because it's aim to find a user whatever it's given (email, name,
// login, etc).
$sys_ldap_search_user='(|(uid=%words%)(cn=%words%)(mail=%words%))';
// By default tooltip search is using ($sys_ldap_cn=%words%*) search filter (Hardcoded)
// You can change for a more sophisticated search
// $sys_ldap_tooltip_search_user='(&(|(sn=%words%*)(givenName=%words%*)(uid=%words%*))(!(givenName=BoiteVocale))(uid=*))';
// By default tooltip search attrs are $sys_ldap_cn and $sys_ldap_uid (Hardcoded)
// You can choose the attributes the search will retrieve
// $sys_ldap_tooltip_search_attrs='uid;sn;givenName';
// On account creation, what it the default user status (A, R, ...)
$sys_ldap_default_user_status = 'A';
// Enable LDAP based authentication for SVN by default for new projects
$sys_ldap_svn_auth = 1;
// Enable LDAP daily synchronization
$sys_ldap_daily_sync = 1;
// Enable usage of LDAP for people management. For instance autocompletion on
// user list, automatic creation of users not already referenced in the forge.
$sys_ldap_user_management = 1;
// Enable ldap group management.
// This allows to mirror a LDAP group defined in LDAP directory within the forge
// Doesn't work yet with only works with OpenLDAP compatible directories yet.
$sys_ldap_grp_enabled = 1;
// Specific DN where the user groups are
$sys_ldap_grp_dn = 'ou=groups,dc=techhub,dc=lt';
// Field that reprsent group name
$sys_ldap_grp_cn = 'cn';
// Field that indicate the membership of a user in a group
$sys_ldap_grp_member = 'uniquemember';
?>
AND gerrit.conf
[gerrit]
basePath = git
canonicalWebUrl = http://techhub.lt:2401/
[database]
type = H2
database = db/ReviewDB
[sendemail]
smtpServer = localhost
[container]
user = root
javaHome = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.45.x86_64/jre
[sshd]
listenAddress = *:29418
[httpd]
listenUrl = http://*:2401/
[cache]
directory = cache
[auth]
type = LDAP
[ldap]
server = ldap://techhub.lt
accountBase = ou=people,dc=cro,dc=techhub,dc=lt
groupBase = ou=group,dc=cro,dc=techhub,dc=lt
accountFullName = cn
That's 2 different problems.
Do you manage to authenticate with LDAP accounts on gerrit ?
If yes, I think the problem comes from "$sys_ldap_eduid = 'eduid';" parameter in tuleap ldap config. This attribute should be the unique identifier of one's account in ldap (either you have such an attribute of you can use 'uid' as a fallback.

Which parameter is used for authentication in LDAP

In case of LDAP authenticaion, what are the parameters that are generally used for authentication. I guess using DN would be a headache for users logging in via ldap because it is too large to remember.
How is the option of using uid or sAMAccountName for authentication where in my implementation, I retrieve the dn of the corresponding uid or sAMAccountName and proceed to authentication.
Am I going the right track?
In LDAP, a connection or session can be authenticated. When an LDAP client makes a new connection to an LDAP directory server, the connection has an authorization state of anonymous. The LDAP client can request that the authorization state be changed by using the BIND request.
A BIND request has two forms: simple and SASL. Simple uses a distinguished name and a password, SASL uses one of a choice of mechanisms, for example, PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, GSSAPI, and EXTERNAL - all of which except for GSSAPI and EXTERNAL are too weak to use in production scenarios or mission-critical areas.
To Use the simple BIND, construct a BIND request and transmit it to the LDAP directory server. The LDAP directory server will respond with a BIND response in which is contained a result code. The result code is an integer, anything other zero indicates that the BIND request failed. If the result code is zero, the BIND request succeeded and the session authorization state has been changed to that of the distinguished name used in the BIND request.
Each subsequent BIND request on the same connection/session causes the authorization state to be set to anonymous and each successive successful BIND request on the same connection/session causes the authorization state to be set to the authorization state associated with the authentication ID, which is the distinguished name in the case of the simple BIND, but might be something else entirely where SASL is used - modern professional quality servers can map the incoming names to different DNs.
Whichever language is used, construct a BIND request, transmit it to the server, and interpret the response.
Update:
If the distinguished name is not known, or is too cumbersome (often the case with web application users who don't know how they are authenticated and would not care if they did know), the LDAP application should search the directory for the user. A successful search response always contains the distinguished name, which is then used in a simple BIND.
The search contains at a minimum, the following:
base object: a distinguished name superior to the user, for example, dc=example,dc=com
a scope: base level, one level below base, or subtree below base. For example, if users are located subordinate to ou=people,dc=example,dc=com, use base object ou=people,dc=example,dc=com and a scope of one-level. These search parameters find entries like: uid=user1,ou=people,dc=example,dc=com
a filter: narrows down the possible search results returned to the client, for example (objectClass=inetOrgPerson)
a list of requested attributes: the attributes from an entry to return to the client. In this case, use 1.1, which means no attributes and returns on the DN (distinguished name), which is all that is required for the simple BIND.
see also
the links in the about section here
LDAP servers only understand LDAP queries; they don't have "usernames" like you and I are used to.
For LDAP, to authenticate someone, you need to send a distinguished name of that person's (or entity's) entry in LDAP; along with their password.
Since you mentioned sAMAccountName I am assuming you are working with Active Directory. Active Directory allows anonymous binds - this means you can connect to it without providing any credentials; but cannot do any lookups without providing credentials.
If you are using python-ldap and Cython (and not IronPython which has access to the various .NET APIs that make this process very easy); then you follow these steps.
Typically you use a pre-set user that has appropriate rights to the tree, and connect to the directory with that user first, and then use that user's access for the rest of the authentication process; which generally goes like this:
Connect to AD with the pre-set user.
Query active directory with the pre-set user's credentials and search for the distinguished name based on the sAMAccountName that the user will enter as their "username" in your form.
Attempt to connect again to Active Directory using the distinguished name from step 2, and the password that the user entered in their form.
If this connection is successful, then the user is authenticated.
So you need two main things:
The login attribute (this is the "username" that LDAP understands)
A LDAP query that fetches information for your users
Following is some rough code that can do this for you:
AD_USER = 'your super user'
AD_PASSWORD = 'your super user password'
AD_BIND_ATTR = 'userPrincipalName' # this is the "login" for AD
AD_URL = "ldap://your-ad-server"
AD_DN = "DC=DOMAIN,DC=COM"
AD_LOGIN_ATTR = 'sAMAccountName' # this is what you user will enter in the form
# as their "login" name,
# this is what they use to login to Windows
# A listing of attributes you want to fetch for the user
AD_ATTR_SEARCH = ['cn',
'userPrincipalName',
'distinguishedName',
'mail',
'telephoneNumber','sAMAccountName']
def _getbinduser(user):
""" This method returns the bind user string for the user"""
user_dn = AD_DN
login_attr = '(%s=%s)' % (AD_LOGIN_ATTR,user)
attr_search = AD_ATTR_SEARCH
conn = ldap.initialize(AD_URL)
conn.set_option(ldap.OPT_REFERRALS,0)
conn.set_option(ldap.OPT_PROTOCOL_VERSION,3)
try:
conn.bind(AD_USER,AD_PASSWORD)
conn.result()
except:
exceptionType, exceptionValue, exceptionTraceback = sys.exc_info()
# Exit the script and print an error telling what happened.
sys.exit("LDAP Error (Bind Super User)\n ->%s" % exceptionValue)
try:
result = conn.search_s(user_dn,
ldap.SCOPE_SUBTREE,
login_attr, attr_search)
except:
exceptionType, exceptionValue, exceptionTraceback = sys.exc_info()
# Exit the script and print an error telling what happened.
sys.exit("LDAP Error (Search)\n ->%s" % exceptionValue)
# Return the user's entry from AD, which includes
# their 'distinguished name'
# we use this to authenticate the credentials the
# user has entered in the form
return result[0][1]
def authenticate(user,password):
bind_attr = AD_BIND_ATTR
user_dn = AD_DN
login_attr = '(%s=%s)' % (AD_LOGIN_ATTR,user)
data = _getbinduser(user)
if len(data) == 1:
return None
# Information we want to return from the directory
# for each user, season to taste.
info = {}
info['name'] = data['cn'][0]
info['email'] = data['mail'][0]
try:
info['phone'] = data['telephoneNumber'][0]
except KeyError:
info['phone'] = 'Not Available'
conn = ldap.initialize(Config.AD_URL)
conn.set_option(ldap.OPT_REFERRALS,0)
conn.set_option(ldap.OPT_PROTOCOL_VERSION,3)
try:
# Now we have the "bind attribute" (LDAP username) for our user
# we try and connect to see if LDAP will authenticate
conn.bind(data[bind_attr][0],password)
conn.search(user_dn,ldap.SCOPE_SUBTREE,login_attr,None)
conn.result()
return info
except (ldap.INVALID_CREDENTIALS,ldap.OPERATIONS_ERROR):
return None
One small expansion on Terry's excellent comment. If you store all your users in the same part of the DIT, and use the same attribute to identify them, you can programmatically construct the DN, rather than searching for it.