Looking for some clarification on how incremental sync works / does. I have recently configured Ranger/AD sync with incremental sync off and the user search filter blank. This resulted in all users from AD being added to Ranger.
This was just intended as a base-case test, but when adding a new user search filter for the Ranger AD configs in Ambari and restarting the Ranger service, no changes appear to have been made (which is what I had expected when setting incremental sync to off) and ALL of the AD users are still visible, not just the ones specified by the filter. At this point have a some questions:
If I were to go into the Ranger UI and go to the users and groups menu and manually delete all of the AD users and groups, then add the user search filter to the Ranger configs, and restart Ranger would that wipe the rest of the users from Ranger's user DB and leave only the AD users from the search filter once Ranger was restarted? Any other way to get this desired result?
What would happen if accidentally manually deleted a unix user from the users and groups menu in the Ranger UI? Would they repopulate once restarted Ranger or would I need to something else to fix the mistake?
From the Apache email list...
Once Users are Groups are sync'd to Ranger DB, deleting them is an admin only manual operation. Ranger doesn't delete users and groups automatically based on the search filter changes. But once you cleanup the users are groups and restarting ranger usersyn should pull in only the users and groups based on the configured filter.
Just an FYI - For testing purposes, ranger usersync supports one config "ranger.usersync.policymanager.mockrun" which can be set to true so that the sync'd users and groups are not updated to ranger DB. https://docs.cloudera.com/HDPDocuments/HDP3/HDP-3.1.4/installing-ranger/content/ranger_install_configure_ranger_user_sync.html
If a user/group is deleted from Ranger UI, once ranger is restarted, these users/groups are sync'd to Ranger DB based on the sync configuration.
So from these points, note that if the default HDP / hadoop users (eg. hdfs, yarn, livy) were created as unix users on each machine in cluster (eg. what HDP 3.1.0 does by default) and you manually delete these users from the Ranger UI, they will not reappear once Ranger restarted. That is, Ranger will not look at both AD and local unix users (perhaps there is a way to change this in configs?). So what you would need to do then is switch Ranger user sync to "unix", restart Ranger to let the local unix users sync, then switch configs to AD and restart again to get the AD users into Ranger (and the previously synced unix users should still be there since Ranger does not delete users based on the user sync configs).
Related
I'm struggling with duplicated users in my Jenkins and Not sending mail to unregistered user ... problem.
I installed the plugin as per this answer but cannot configure it properly by reading the plugin documentation.
My jenkins collects data from Active Directory and some users have duplicated entry, e.g.:
john.doe, john.doe#mycompany.com -> duplicated user which is detected by Jenkins
doej, john.doe#mycompany.com -> correct user which is used when logging in
Jenkins after collecting responsible people from git changes in job ends with
Not sending mail to unregistered user john.doe#mycompany.com
I tried adding additional identity to user doej by setting:
Identity: john.doe#mycompany.com
Realm: <empty>
but it doesn't work.
How should I configure correctly the Additional Identities Plugin?
Seems it's not possible to configure the additional identity plugin in Jenkins for merge the duplicate user
As Jenkins is missing a way to ensure users unicity(unique) since they are created from various sources: authentication method (LDAP in my case), code commits (Subversion, Mercurial, Git, ...).
Depending on the way the user is retrieved by Jenkins (from a commit on a given SCM or its authentication), multiple identities are created for the same real user.
As a consequence, some features are not fully or badly working (login, notifications, user's builds, continuous integration game, ...) and configuration of users is a pain as it must be done multiple times for each real user.
Still the required features are:
a merging features. Allow to merge multiple Jenkins users into a single account.
a user pattern per SCM. Allow to choose how to extract a username from a commit for each SCM and how to optionally match existing one instead of creating a new user.
an id pattern per notification type. Allow to define how to generate the default id used for notification from the user data (from his jenkins id, his name, his scm id, ...): for instance, his mail or his jabber id, ...
Reference: [JENKINS-10258] Allow users unicity - Jenkins Jira
Solution is Jenkins 1.480 but this is still in Vulnerabilities state and have bug as well.
Jenkins 1.480 introduces an extension point to resolve jenkins user "canonical" ID when searching for user in Database by id or full name. This plugin uses this extension point to let user configure external identities as user properties.
You can reach out to Jenkins community or Support team to know the status or when they will final release
I am trying to set up Jenkins for software hosted in Google Cloud VM. I have a VM with user account A and user account B. Jenkins is hosted in user account A. All the other softwares are hosted in user account B. In order to authorize Jenkins to ssh into userB#VM_ADDRESS, I am placing user A's .ssh/id_rsa.pub into user B's .ssh/authorized_keys. This allows for Jenkins to ssh into userB#VM_ADDRESS to update my software whenever I push changes to Github. However, after awhile, for some reason the .ssh/authorized_keys in user account B is replaced/refreshed and my key is gone, and the ssh from Jenkins would fail with permission denied. How should I solve this? Or am I doing Jenkins wrong?
I saw this thread at https://groups.google.com/g/gce-discussion/c/iHqRb2KlMZg/m/x59xV4pYAQAJ?pli=1 that seems to be a similar problem but after reading through I still do not know what I need to do.
The SSH keys in the metadata are redeployed regularly. To solve the issue, instead of performing manually the copy/paste in the system, copy the key and (add it to the compute engine metadata](https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys)
However, I'm not sure that is the good way to follow. Why you don't log in with the account A, because it's the "reality" and perform action on software? You can put the account A and the account B in the same Linux group, or performing a chown to change the owner of the fresh files at the end.
What's the requirements behind this tricky question?
Update 1:
The fact to use the key of the account A to log into the user B, is like an impersonation. At the end, you don't know if it's the user account A or B which have performed stuff on your file.
Anyway, in linux you have 3 level of permission UGA (User, Group, All), that's why you have something like this when you perform a ls -la: rwxr-xr-- which mean U (User) can do RWX (Read Write eXecute), group can only Read and eXecute and all can only read.
Therefore, if the user account A and user account B are in the same Group, you can set common group permissions and avoid all (others) to access to the files.
I have configured AD on my jenkins server.
Everything is working fine, but in case AD server goes down, I wanna have a fallback user.
I know that AD plugin allows you to do that, but I'm confused with part
Use Jenkins Internal Database and select user this selected user must exist on Jenkins internal DB right?
I have no user create internally, so How can create that user internally? Because I have AD integrated already.
Thank you
The internal user database means XML files under $JENKINS_HOME/users.
The first time you log in with the fallback user, it will update the XML files.
Before the first login, you cannot use the Use Jenkins Internal Database feature.
I discover this behavior reading the source code of the change (full story here (github page)).
I am in the process of switching the LDAP backend that we use to authenticate access to Gerrit.
When a user logs in via LDAP, a local account is created within Gerrit. We are running version 2.15 of Gerrit, and therefore our local user accounts have migrated from the SQL DB into NoteDB.
The changes in our infrastructure, mean that once the LDAP backend has been switched, user logins will appear to Gerrit as new users and therefore a new local account will be generated. As a result we will need perform a number of administrative tasks to the existing local accounts before and after migration.
The REST API exposes some of the functionality that we need, however two key elements appear to be missing:
There appears to be no way to retrieve a list of all local accounts through the API (such that I could then iterate through to perform the administrative tasks I need to complete). The /accounts/ endpoint insists on a query filter being specified, which does not appear to include a way to simply specify 'all' or '*'. Instead I am having to try and think of a search filter that will reliably return all accounts - I haven't succeeded yet.
There appears to be no way to delete an account. Once the migration is complete, I need to remove the old accounts, but nothing is documented for the API or any other method to remove old accounts.
Has anybody found a solution to either of these tasks that they could share?
I came to the conclusion that the answers to my questions were:
('/a/' in the below examples is accessing the administrative endpoint and so basic Auth is required and the user having appropriate permissions)
Retrieving all accounts
There is no way to do this in a single query, however combining the results of:
GET /a/accounts?q=is:active&n=<number larger than the number of users>
GET /a/accounts?q=is:inactive&n=<number larger than the number of users>
will give effectively the same thing.
Deleting an account
Seems that this simply is not supported. The only option appears to be to set an account inactive:
DELETE /a/accounts/<account_id>/active
I've got an issue with Jenkins 2.6-1.1 running on CentOS v7.2.1511. I am using the Crowd 2 integration plugin v.1.8 and the Matrix Authorization Strategy plugin v.1.3.2 for authentication and authorization, respectively. Security is configured for "Project-based Matrix authorization strategy".
In my Jenkins configuration, I employ two group assignments on the Crowd server: jenkins-administrators and jenkins-users. jenkins-admininstrators has every permission enabled. jenkins-users have permission to:
Overall: Read, RunScripts
Agent: Build, Configure, Connect, Create
Job: Build, Cancel, Configure, Create, Delete, Discover, Read, Workspace
Run: Delete, Update
View: Configure, Create, Read
SCM
jenkins-administrators obviously have all of these permissions enabled as well.
The issue is that, at some point, users who are in both jenkins-administrators and jenkins-users ceased having the ability to configure nodes or create new nodes. What I mean by this is that, when the user clicks on the link to configure a node, or clicks OK on the new node (/computer/node) page, the post goes through, but a page is never returned.
If I remove the user from the jenkins-administrators group, they are able to add and configure nodes as expected.
If I configure the user such that they are in the jenkins-admininstrators group solely, they are unable to login (which seems like it could be related).
I tried modifying the security matrix so that jenkins-administrators and jenkins-users had the same configuration in re: to nodes, but this didn't change anything.
Outside of the slave logs, and the occasional message to /var/log/messages, there doesn't appear to be anything relevant in /var/log/jenkins/jenkins.log.
Any suggestions on how I can configure Jenkins logging to show me information that is more relevant to node configuration and creation, or any suggestions in general on how I might observe the node creation and configuration process?