Background:
By default the Sentry service has the users hive, hue and impala as the sentry admins. This is w.r.t to the property on Cloudera Manager (CM) sentry.service.admin.group. I want to add a user or group which has my user account, so that I can become the Sentry admin.
Current environment:
Cloudera 5.4.7 with CM
Postgres databases for CDH, Hive and Sentry
Sentry version 1.4
Question:
I have integrated OpenLDAP so that Beeline authentication can be done through LDAP user and password credentials. Before LDAP integration to HiveServer2, I used root as the Sentry admin, (Beeline does not strictly check for password without LDAP) so I could execute commands like show roles; and create roles; as root.
Now with LDAP integrated I cannot login as root, since it does not have an entry on the LDAP server and adding it there is not an option, so I want to add a user called johndoe as the admin for Sentry so that he can create roles like how root did.
Is this something that I need to set at a Postgres level? I mean by entering the Sentry database and GRANT'ing some privilege there?
What have I tried so far:
I have tried all combinations of using local users in the property sentry.service.admin.group, adding local users to the hive group, using LDAP users, LDAP groups - Nothing !
I don't understand where it is going wrong. Or is it that Sentry only identifies hive, hue and impala as the admins.
Any help would be greatly appreciated. Stuck on this for ten days now.
You need to use the Unix group to which the Unix-User you are using belongs. Sentry can only use the Unix group, which in the case of Hive, Hue and Impala in the default configuration is hive, hue and impala.
Sentry cannot use LDAP groups. You need to use Unix groups in the setting sentry.service.admin.group.
Related
I have a terraform code that deploys Azure SQL database with server admin credentials. But I would like to create a separate user and login on the Database with dbo permissions. Could someone please help with terraform code for this?
Maybe you can reference this blog: How to create database user and assign role to it with terraform:
I've started working on a Terraform provider that will do this over at https://github.com/jayway/terraform-provider-mssql. It's still very early work, but I've managed to make it provision logins and users for those logins in a local SQL Server instance (that was already running, so I haven't tested it at all in conjunction with e.g. the AzureRM provider). Testing and contributions are very welcome (but don't use it for production scenarios just yet)!
User sumit salunke accepted(marked) it as answer, I think it should works.
Hope this helps.
We updated our Couchbase from 4.6 Community edition to 5.0.0-2873 Enterprise Edition for testing purposes and our software using the java-client started throwing InvalidPasswordException when trying to open a bucket.
As I've found, every newly created bucket has authType='sasl' and a randomly generated saslPassword.
I've tried creating a bucket using the CLI instead of the GUI:
couchbase-cli bucket-create -c localhost:8091 -u Administrator -p password --bucket=general --bucket-ramsize=1300 --bucket-type=couchbase --bucket-password=
I got the following error:
ERROR: unrecognized arguments: --bucket-password=password
I also tried the bucket-edit function with the same result.
According to the documentation the argument should be valid.
I also tried using the REST API to change bucket authentication (and similarly password), but even though this didn't throw any erros, the authType and the password remained the same.
curl -X POST -u Administrator:password -d 'authType=none' http://<host>:8091/pools/default/buckets/general
Again, according to the documentation this should work.
If I query the bucket information for the sasl password and provide that for the openBucket function then the connection works, however we really don't want to use this feature in our system.
So, any other ideas how it would be possible to remove the bucket authentication in our 5.0EE Couchbase setup?
In Couchbase 5.0 we no longer support bucket passwords and have moved to using role based access control when connecting to buckets. This means that in 5.0 the standard (pre-production) way to connect to a bucket is by using the Administrator user and password that you created when setting up the cluster. In case you're unsure what the Administrator user is, it is the user you create when you first go through the Couchbase setup wizard or the it is the username and password you specify on the command line when running the couchbase-cli cluster-init command.
One thing to note is that using the Administrator user/password is the standard pre-production workflow. I would recommend that when you go into production you create separate users for your application which only have access to cluster resources they need to access in the cluster. You can do this by going to the Users tab in the Administration Console and creating a new user and giving them the Full Bucket Access role which is the standard role that applications should have.
You might now be saying to yourself that this all sounds great, but when I use the Administrator user/password I still am having issues. If this is the case the reason is because you have Couchbase 5.0, but your SDK is not new enough to handle the new RBAC authentication mechanism in 5.0. The workaround for this is to create a user in the Users tab with the same name as the bucket and give that user the Full Bucket Access role. You can then use this user to authenticate.
One last thing to mention is that during an upgrade from a pre-5.0 cluster to a 5.0 cluster Couchbase will automatically create a user for each bucket. The each user will have the same name as one of the buckets and the password for that user will correspond to the bucket password. This is done mainly to ensure that there is no application downtime during an upgrade. After upgrading the cluster the next step should ideally be to upgrade the Couchbase client library to have it start using RBAC authentication.
If you need to stay with old approach and no password you can use cochbase-cli with --rbac-username and --rbac-password "", but you need to specify password as "", e.g.
./couchbase-cli user-manage -c localhost:8091 -u Admin -p password --set --rbac-username <UserForBucket> --roles bucket_full_access[<BucketName>] --rbac-password "" --auth-domain local
I'm using sonar 5.6 LTS with LDAP plugin 2.1.0.
The basic LDAP configuation is working fine. Sonar can connect to LDAP (in my case active directory). sonar.log:
Test LDAP connection on ldaps://ldap.mycompany:636: OK
My user mapping is
ldap.user.baseDn=OU=Users,OU=Accounts,DC=mycompany
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
When I try to login with mycompany\tobi sonar logs:
DEBUG web[o.s.p.l.LdapUsersProvider] Requesting details for user mycompany\tobi
...
DEBUG web[o.s.p.l.LdapUsersProvider] User mycompany\tobi not found in <default>
This makes sense as sAMAccountName contains the value tobi and not mycompany\tobi. But when using just tobi as login, sonarqube does not connect to LDAP for authentication. I just get "Authentication failed" and the log file contains only
DEBUG web[http] POST /sonar/sessions/login | time=235ms
Any ideas why sonarqube does not always use LDAP? Thanks, Tobi
Thanks to Godin, I've finally found the answer:
The root cause is that I had a local account with the same login credentials before using LDAP. When removing users using the web interface, they are not removed permanently from the database. Instead, they are just deactivated.
I connected to the (postgresql) database and in the users table there were still all old local accounts. So I just changed the login column of all deprecated local accounts with
UPDATE users SET login='username_local' WHERE login='username'
As those accounts are deactivated, they cannot be used to login into sonarqube but should not be removed as some other tables might still have references to them.
I need your help in resolving an issue related to Hive Permission. I have enabled Sentry in CDH 5.5 environment but Kerberos is not sent. I could not able to create roles or grant permission to hive objects. For every access need to login through root and sudo to hive and access the object.
When i try su to hive from hdfs user and try giving below command
set role admin;
FAILED: SemanticException The current builtin authorization in Hive is incomplete and disabled.
Please suggest me how to resolve this.
Thanks & Regards
I setup a little server and have it authenticating with ldap.. is there a way to restrict which ldap user can login via ssh without adding an account to the opensuse box?
1 - Create a group on LDAP using YaST's User and Group Management, for instance "serveradmins".
This will create a entry on your LDAP server under the group OU.
2 - Add the allowed users to this group, also using YaST
3 - On the servers you want to restrict the access, edit the /etc/ldap.conf, making sure the following instructions are present (uncommented), mind changing the DC= parts to your configuration:
pam_groupdn cn=serveradmins,ou=group,dc=example,dc=com
pam_member_attribute member
Let me know if this worked well for you. I have this working on OpenSUSE and Ubuntu machines.