How to configure RabbitMQ with LDAP for AD Groups? - rabbitmq

I had managed to configure RabbitMQ with LDAP and authenticate it, if it is for an individual AD account. I am using the following configurations:
RabbitMQ Config file:
auth_backends,[{rabbit_auth_backend_ldap, rabbit_auth_backend_internal},rabbit_auth_backend_internal]
In RabbitMQ management, I had manually created a username with no password set (it works). But, lets say I have an AD Group (called "Rabbit User Group") that has 3 users inside (User1, User2, User3).
The location of the "Rabbit User Group" is in:
sample.companyname.com > City Name (OU) > Groups (OU) > IT Groups (OU) > "Rabbit User Group" (Security Group)
How should I configure it in RabbitMQ management and also for the config file so that, once I update the particular group, all members inside the group will be able to authenticate and have the same permissions (e.g. only this group has admin rights) in RabbitMQ?
I want to avoid needing to manually create each individual user in the RabbitMQ management for authentication?.
I had added the following into my RabbitMQ config file
{
tag_queries, [
{administrator,{in_group,'CN="Rabbit User Group",OU="City Name", OU=Groups, OU="IT Group",DC=sample,DC=companyname,DC=com',"uniqueMember"}},
{management, {constant, true}}
]
}
and tried creating a username called "Rabbit User Group" into the RabbitMQ management without a password. But when I tried to login as "User1", I am unable to log in.
This is my overall config file:
[
{
rabbit,
[
{
auth_backends,[{rabbit_auth_backend_ldap, rabbit_auth_backend_internal},rabbit_auth_backend_internal]
}
]
},
{
rabbitmq_auth_backend_ldap,
[
{servers, ["sample.companyname.com","192.168.63.123"]},
{dn_lookup_attribute, "userPrincipalName"},
{dn_lookup_base, "DC=AS,DC=companyname,DC=com"},
{user_dn_pattern, "${username}#as.companyname.com"},
{use_ssl, false},
{port, 636},
{log, true},
{
tag_queries, [
{administrator,{in_group,'CN="Rabbit User Group",OU="City Name", OU=Groups, OU="IT Group",DC=sample,DC=companyname,DC=com',"uniqueMember"}},
{management, {constant, true}}
]
}
]%% rabbitmq_auth_backend_ldap,
}
].

You need to set the "dn_lookup_attribute" to distinguishedName (DN) instead of the userPrincipalName / sAMAccountName so that it will use this user's DN for member checking in the in_group. As shown below:
{dn_lookup_attribute, "distinguishedName"},
{user_dn_pattern, "CN=${username},OU=Users,DC=sample,DC=companyname,DC=com"},
Instead of:
{dn_lookup_attribute, "userPrincipalName"},
{user_dn_pattern, "${username}#as.companyname.com"},
Microsoft Active Directory and OpenLDAP are different LDAP service flavors and have different user list attribute for groups. The Microsoft Active Directory Group for the users list is called "member" while the OpenLDAP group is called "uniqueMember".
Overall config file:
[
{
rabbit,
[
{
auth_backends, [rabbit_auth_backend_ldap, rabbit_auth_backend_internal]
}
]
},
{
rabbitmq_auth_backend_ldap,
[
{servers, ["sample.companyname.com","192.168.63.123"]},
{dn_lookup_attribute, "distinguishedName"},
{dn_lookup_base, "DC=AS,DC=companyname,DC=com"},
{user_dn_pattern, "CN=${username},OU=Users,DC=sample,DC=companyname,DC=com"},
{use_ssl, false},
{port, 636},
{log, true},
{
tag_queries, [
{administrator,{in_group,"CN=Rabbit User Group,OU=City Name, OU=Groups, OU=IT Group,DC=sample,DC=companyname,DC=com","member"}},
{management, {constant, true}}
]
}
]%% rabbitmq_auth_backend_ldap,
}
].

Related

OPA authorization policies with scopes and roles

I'm using Open Policy Agent as an authorization component together with OIDC enabled apps.
I have input from the apps in the format:
{
"token": {
"scopes": [
"read:books",
"write:books"
]
},
"principal": {
"roles": [
"user",
"moderator"
]
},
"context": {
"action": "read",
"resource": "books"
}
}
Then I have data with access mapping in the format:
{
"user": [
"read:books"
],
"moderator": [
"read:books",
"write:books"
],
"administrator": [
"read:books",
"write:books",
"read:store",
"write:store"
]
}
And the policy currently looks like this:
package whatever.authz
context_scope := concat(":", [input.context.action, input.context.resource])
default allow = false
allow {
token_has_context_scope
principal_has_resource_access
}
token_has_context_scope {
context_scope == input.token.scopes[_]
}
principal_has_resource_access {
principal_role := input.principal.roles[_]
context_scope == data[principal_role][_]
}
This produces the following error:
2 errors occurred:
policy.rego:16: rego_recursion_error: rule principal_has_resource_access is recursive: principal_has_resource_access -> principal_has_resource_access
policy.rego:7: rego_recursion_error: rule allow is recursive: allow -> principal_has_resource_access -> allow
It is the recursive lookup in the principal_has_resource_access function that is causing the error.
I need to check if one of the roles of the principal is allowed to access the resource as specified by the context. Since roles is an array i need to find the union of all access scopes in the data and see if one of them matches the context scope. What am I doing wrong in the policy?
The snippet can be found in the Rego Playground https://play.openpolicyagent.org/p/KhovLRgMup
OPA stores all data under the data path, including policy and rules. There's no way for the compiler to know that the input you're providing isn't referencing the policy itself (i.e. data["whatever"]) which would be recursive. The easiest way to work around this is to simply use a top level attribute for your data which differs from your policy (i.e package name), like this:
{
"attributes": {
"user": [
"read:books"
],
"moderator": [
"read:books",
"write:books"
],
"administrator": [
"read:books",
"write:books",
"read:store",
"write:store"
]
}
}
And update your policy to reference this:
context_scope == data["attributes"][principal_role][_]
Since data.attributes != data.whatever.authz there is no risk of recursion, and the compiler won't complain. You might want a better name than "attributes", but I'll leave that to you :)

Amplify/Cognito no analytics data showing in Pinpoint

No data from my user events is showing up in pinpoint.
I have a frontend react native app which uses the Amplify Auth library configured as:
Amplify.configure({
Analytics: {
AWSPinpoint: {
region: ENV.REGION,
appId: ENV.PINPOINT_APP_ID,
},
},
Auth: {
region: ENV.REGION,
userPoolId: ENV.USER_POOL_ID,
userPoolWebClientId: ENV.USER_POOL_CLIENT_ID,
authenticationFlowType: ENV.AUTHENTICATION_FLOW_TYPE,
oauth: {
domain: ENV.OAUTH_DOMAIN,
scope: ["email", "openid", "profile"],
redirectSignIn: appConfig.scheme,
redirectSignOut: appConfig.scheme,
responseType: "code",
urlOpener,
},
federationTarget: "COGNITO_USER_POOLS",
},
..
In the backend I connected Cognito with pinpoint and use an IAM role with the following policies:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cognito-idp:Describe*"
],
"Resource": "*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"mobiletargeting:UpdateEndpoint",
"mobiletargeting:PutEvents"
],
"Resource": [
"arn:aws:mobiletargeting:eu-west-1:73463623453:apps/my-pinpoint-project-id/*"
]
}
]
}
When I use the app to log in. No data appears in pinpoint.
However, when I do the same using the cli, then the data does show up in pinpoint:
AWS_DEFAULT_PROFILE=novasport-dev aws cognito-idp initiate-auth --auth-flow USER_PASSWORD_AUTH --auth-parameters USERNAME=05ac342c-2134-48f9-b124-b1favc5d0bb1,PASSWORD=myPwd --client-id myWebClienId --analytics-metadata AnalyticsEndpointId=my-pinpoint-project-id
It seems like in my FE app the Amplify Auth library is not able to send the data to pinpoint. When I track the network request I also don't see a call being executed that represents the analytics data.
How can I get the analytics data from my FE app to Pinpoint? Am I missing some configuration?
EDIT
We are using the modular imports of Amplify as such
import Amplify from "#aws-amplify/core";
package.json:
"#aws-amplify/api": "4.0.3",
"#aws-amplify/api-graphql": "2.0.3",
"#aws-amplify/auth": "4.0.3",
"#aws-amplify/core": "4.1.1",
Go and check Cognito Identity Pool -> select the Identity Pool which includes your app name --> Edit Identity Pool --> Authentication Provider --> Cognito --> check these values ===> User Pool Id, App client Id and Authenticated role selection.
In my case, setting the 'Authenticated role selection' to 'Use default role' solved the issue.

Problem in enable Authenticate Mesos APIs in Mesosphere/ DCOS

Authentication is not enable for Mesos APIs by default.
After Install DCOS I want config Mesos API Authentication on it.
I'm going to set authentication for mesos APIs like : register_frameworks, run_task,...
the problem is after my configuration, DCOS GUI and marathon dosent work correctly.
I configured DCOS as follow:
Mesos environment variable config:
path:/opt/mesosphere/etc/mesos-master
#Authentication part
MESOS_LOG_DIR=/var/log/mesos
#Framework authentication
MESOS_AUTHENTICATORS="crammd5"
MESOS_AUTHENTICATE_FRAMEWORKS=true
MESOS_AUTHENTICATE_HTTP_FRAMEWORKS=true
MESOS_HTTP_FRAMEWORK_AUTHENTICATORS="basic"
MESOS_ACLS=/opt/mesosphere/etc/acls
MESOS_AUTHENTICATE=true
MESOS_CREDENTIALS=/opt/mesosphere/etc/mesos_credentials_auth.json
MESOS_ROLE=foo
Marathon environment variable config:
path:/opt/mesosphere/marathon
#authentication section
MARATHON_MESOS_AUTHENTICATION=enabled
#MARATHON_HTTP_CREDENTIALS=marathon:123456
MARATHON_MESOS_AUTHENTICATION_PRINCIPAL=marathon
MARATHON_MESOS_ROLE=foo
MARATHON_MESOS_AUTHENTICATION_SECRET_file=/opt/mesosphere/etc/marathon.secret
Marathon environment variable config: path:/opt/mesosphere/metronome
METRONOME_MESOS_AUTHENTICATION_ENABLED=true
METRONOME_MESOS_AUTHENTICATION_PRINCIPAL=metronome
METRONOME_MESOS_ROLE=foo
METRONOME_MESOS_AUTHENTICATION_SECRET_FILE= /opt/mesosphere/etc/metronome.secret
/opt/mesosphere/etc/metronome.secret (contain metronome secret without new line)
123456
/opt/mesosphere/etc/marathon.secret (contain marathon secret without new line)
123456
/opt/mesosphere/etc/acls
{
"run_tasks": [
{
"principals": {
"type": "ANY"
},
"users": {
"type": "ANY"
}
}
],
"register_frameworks": [
{
"principals": {
"type": "ANY"
},
"roles": {
"type": "ANY"
}
}
]
}
/opt/mesosphere/etc/mesos_credentials_auth.json
{
"credentials" : [
{
"principal": "principal1",
"secret": "secret1"
},
{
"principal": "principal2",
"secret": "secret2"
},
{
"principal": "marathon",
"secret": "123456"
},
{
"principal": "metronome",
"secret": "123456"
}
]
}
When I enable this configuration and stop and start dcos-mesos-master:
systemctl stop dcos-mesos-master.service
systemctl start dcos-mesos-master.service
systemctl stop dcos-marathon.service
systemctl start dcos-marathon.service
systemctl stop dcos-metronome.service
systemctl start dcos-metronome.service
http://IP/services page in DCOS dosnt work. I think its beacuase authentication of marathon don't set correctly. bcs this address dosent work after enable authentication configuration:\
http://IP/service/marathon/v2/deployments?_timestamp=1560449507192
I got this errors in mesos log after enable metronome authentication:
I0613 17:35:12.176092 305 authenticator.cpp:98] Creating new server
SASL connection
I0613 17:35:12.177258 304 master.cpp:10255] Re-authenticating
scheduler-aca98ea7-be34-49d1-9200-5ef8c15da153#172.17.0.2:15201;
discarding outstanding authentication
I0613 17:35:12.177523 304 master.cpp:10285] Ignoring stale
authentication result of scheduler-aca98ea7-be34-49d1-9200-
5ef8c15da153#172.17.0.2:15201
I0613 17:35:12.177582 304 authenticator.cpp:98] Creating new server
SASL connection
I0613 17:35:12.178586 302 master.cpp:10255] Re-authenticating
scheduler-aca98ea7-be34-49d1-9200-5ef8c15da153#172.17.0.2:15201;
discarding outstanding authentication
I0613 17:35:12.178850 302 master.cpp:10285] Ignoring stale
authentication result of scheduler-aca98ea7-be34-49d1-9200-
5ef8c15da153#172.17.0.2:15201
After search, finally I got my answer:
These security features are only available on "DC/OS mesosphere Enterprise" and you cant config it in open source version.
also I opened github issue with more details:(I hope it will be usefull)
https://github.com/mesosphere/marathon/issues/6942

AWS AMI cannot retrieve password after packer creation using private key

I am building a windows server AMI using packer. It works fine with a hardcoded password, but I am trying to create the AMI so that the password is autogenerated. I tried what was suggested below and the packer logs looks good, it gets a password.
How to create windows image in packer using the keypair
However when I create an EC2 instance from the AMI in terraform the connection to the windows password is lost and cannot be retrieved. What is missing here?
Packer json
{
"builders": [
{
"profile" : "blah",
"type": "amazon-ebs",
"region": "eu-west-1",
"instance_type": "t2.micro",
"source_ami_filter": {
"filters": {
"virtualization-type": "hvm",
"name": "*Windows_Server-2012-R2*English-64Bit-Base*",
"root-device-type": "ebs"
},
"most_recent": true,
"owners": "amazon"
},
"ssh_keypair_name" : "shared.key",
"ssh_private_key_file" : "./common/sharedkey.pem",
"ssh_agent_auth" : "true",
"ami_name": "test-{{timestamp}}",
"user_data_file": "./common/bootstrap_win.txt",
"communicator": "winrm",
"winrm_username": "Administrator"
}
]
}
Adding Ec2Config.exe -sysprep at the end worked.
{
"type": "windows-shell",
"inline": ["C:\\progra~1\\Amazon\\Ec2ConfigService\\Ec2Config.exe -sysprep"]
}
Though beware it seems my IIS configuration does not work after sysprep.

Revoking default permission fails in new Office 365 Group

After a file is uploaded to an Office 365 Group’s OneDrive using the Graph API, we want to revoke the default permissions on the file. However, in groups which have only recently be created, this fails.
By default, a file's permissions are “GroupName Owners”, “GroupName Members” and “GroupName Visitors”. We want to remove these permissions and grant access to specific AD Security Groups.
After uploading a file we are seeing two different results when getting the default permissions (in preparation to delete them).
In one case, we get four permissions – the three listed above, plus a ‘special’ permission which has grantedTo with a user with id matching the group id. We have learned not to delete this permission, as we lose the ability to delete the other permissions.
Here, this ‘special’ permission is the first one listed:
{
"#odata.context": "https://graph.microsoft.com/V1.0/$metadata#drives('b%21Y25ow5oitkOvNToutf7LrYZ-y78P2jBEjoGLzb3oPqnw0a3YKFDwTobjTB4gYxKt')/root/permissions",
"value": [
{
"grantedTo": {
"user": {
"id": "273c2c33-8533-445d-ae65-4b63be296995",
"displayName": "SharePoint Tests"
}
},
"id": "Yzowby5jfGZlZGVyYXRlZGRpcmVjdG9yeWNsYWltcHJvdmlkZXJ8MjczYzJjMzMtODUzMy00NDVkLWFlNjUtNGI2M2JlMjk2OTk1X28",
"roles": [
"write"
]
},
{
"grantedTo": {
"user": {
"displayName": "SharePoint Tests Owners"
}
},
"id": "U2hhcmVQb2ludCBUZXN0cyBPd25lcnM",
"roles": [
"SP.Full Control",
"write"
]
},
{
"grantedTo": {
"user": {
"displayName": "SharePoint Tests Visitors"
}
},
"id": "U2hhcmVQb2ludCBUZXN0cyBWaXNpdG9ycw",
"roles": [
"read"
]
},
{
"grantedTo": {
"user": {
"displayName": "SharePoint Tests Members"
}
},
"id": "U2hhcmVQb2ludCBUZXN0cyBNZW1iZXJz",
"roles": [
"SP.Edit"
]
}
]
}
However, for a period after the group has been created, after uploading a file, we only get 3 permissions back – the special one mentioned above is missing. In this case, trying to delete the other permissions fail with an ‘unauthenticated’ error code. E.g.
DELETE https://graph.microsoft.com/V1.0/drives/b!zn7l0OHTmUa3lGABIbIGQIZ-y78P2jBEjoGLzb3oPqnw0a3YKFDwTobjTB4gYxKt/items/013LUA5IQEPURED3OSURAI27FBHDYLFQJP/permissions/U2FnZSAtIFBBUiBTZWN1cml0eSA0IE93bmVycw
We can still add permissions, just not revoke the default ones.
This condition seems to persist for all files created within a given Office 365 Unified Group until several minutes after it has been created.
Our only option at the moment looks to be to create a dummy file, and see if we get 3 or 4 permissions back (or just try deleting the default permissions). If we only get 3 try again after some time period. But this seems like a fragile hack, and adds significant time (several minutes) to our upload process.
Does anyone have any better suggestions, or an explanation of this behaviour?
Thanks
Peter, Groups files are stored in a SharePoint document library and hence permissions (owners & members) are inherited from the AzureAD and cannot be changed, see this documentation for more information: https://support.office.com/en-us/article/Learn-about-Office-365-groups-b565caa1-5c40-40ef-9915-60fdb2d97fa2?ui=en-US&rs=en-US&ad=US&fromAR=1
You can't break inheritance and please see these additional features we are rolling specific to the SharePoint document library: https://techcommunity.microsoft.com/t5/SharePoint/UPDATE-Create-Office-365-Groups-with-team-sites-from-SharePoint/m-p/48277