I am creating a build envirnoment and freshly installed jenkins with ActiveDirectory/LDAP auth.
We will have external users which should not be able to login to our domain computers but they should have access to jenkins/jira/... in order to develop with us (perhaps vpn for accessing some dev backends).
So for these users in active directory I set a dummy host they are able to logon (which means no computer at all). Jira/Confluence and dav_svn have no problem with this but it seems jenkins checks this property and refuses the access.
Can anybody tell me what "host" I have to put in there so that jenkins accepts a logon of these users? Or if I have to set a hidden config value in jenkins?
The users to accept are all in a special developer group. If I could simply pass the name of the group but even this does not help (matrix based): the user cannot login.
Thanks ver much!
Aurel
Related
Current State: I have implemented project based roles strategy (also called the item roles) and have the appropriate project folder level regex etc set up. And I have verified the regexes and other permissions work fine for most logged in users, except the below scenarios I am running into.
Plugin Version: 3.2
Jenkins Version: 2.263.4
Jenkins Authentication Provider: LDAP Connecting to Active Directory
Example regex(es): for project role dev = ^ABC\-DEF\/DEV\/.*
Issue: Certain users are only having issues while going through the project role based authorization plugin where they are not able to see the option to run builds or job configurations. While the same configurations work for a couple of other user who have the same permissions.
Example:
Users - adm-XXXX and adm-YYYY and a few more all starting with the prefix of adm- are not able to get the roles for the configure and run builds on the jobs based on the above regex.
While Users - adm-zzzz and others are able to get the same roles using the same permission matrix.
The issue is very inconsistent as some days it would work, and even the same configurations when I tested in another Jenkins instance it worked for the user - adm-XXXX so I am at a loss on how to debug why it does not work for a few users consistently. I can understand if it is a configuration issue it should not work for all users having the same role.
Are there any tips on enabling some extra debug to troubleshoot this since there are literally a couple of loggers in the code of the plugin.
Appreciate the help here from any one knowledegable.
I have same issue, where associating an LDAP/AD user to a local global role or item/project role with build and configure permissions enabled does not enable this permission in the project itself. The option to build and configure is not available.
The only way I got around this was to add the users into AD groups and associating the AD Group to a role with required permissions.
Enabling the exact same permissions on the AD group role that I had on the local role, enabled the build and configure option in the projects.
I am not sure if this is a bug, an AD integration issue that you cannot mix/match local and AD roles or I am missing some option or if anyone has managed to get around this anomoly - but this workaournd seems to overcome this.
I'm trying to use the Jenkins TFS Plugin and have trouble authenticating. I saw that user on the TFS administration, and gave it permissions on my project.
I've created a local user account (via Local Users and Groups) - TfsServer\TfsUserAdmin, and I'm trying to use it to authenticate against the TFS server.
I able able to use the name and password of the user. For example this works (though it prints an empty list):
tf workspaces -format:brief -server:http://TfsServer:8080/tfs/Redacted_Collection -login:TfsServer\TfsUserAdmin,RedactedPassword
If I change the password on the above command I get an error, so authentication does work.
The next command is:
tf workspace -new "RedactedWorkspaceName;" -noprompt -server:http://TfsServer:8080/tfs/Redacted_Collection -login:TfsServer\TfsUserAdmin,RedactedPassword
This fails with the error:
TF14045: The identity TfsServer\TfsUserAdmin is not a recognized identity.
I don't think I can change these commands, they are created by the plugin.
I've found people with similar errors, but none of them had the user name at the error - only a GUID or the server name.
Can I work with TFS and a local user?
You will likely need to use Shadow Accounts to get your Jenkins server to talk to TFS...
Create a local user on both your TFS server and your Jenkins server with the same Username & Passowrd. Then use that account to authenticate.
This is the only way to get cross domain coms working without trust and is a feature of Windows & AD. If your org has disabled it you will need to look at creating a trust relationship between your domains.
I have multiple users on a Jenkins server, each with their own credentials for external secured servers needed to run their builds. I am using the credentials plugin to manage the stored credentials. Currently, when a user configures a project, they can use anyones credentials for doing external jobs. I need to make it so that each user only sees the credentials they own when they configure jobs on the jenkins server. How would I do this?
The Folders plugin allows to limit the scope of credentials to a specific folder.
If you're fine with restricting access of different users to different folders (e.g., with the Role Strategy plugin), then this could be a solution.
Just create the folder, enter the folder, then select the "Credentials" link on the sidebar. A new link should appear called "Folder" click that and then define your credentials. Jobs in other folders will not be able to use those.
I am creating an msi-package of a Windows service using Wix. I want to run the service under a regular user account without administrative priviliges. For better security I want to put the files of the service in the personal user folders (such as AppData\Local\Programs\CompanyName... for binaries and AppData\Local\CompanyName... for config and data files) with the appropriate file access permissions for the user. I imagine the following scenario:
Start the msi in the per-machine context.
During the client stage of the installation ask for the user name and password.
During the server stage of the installation:
a) create the user
b) change to its context and install the program files to ProgramFilesFolder and the data files to LocalAppDataFolder
c) change back to the admin context and install and configure the service to be run under the user account
I am stuck at the step 3 b) as from what I've learned I can't change the installation context after switching to the server side of the installation. Please could you advice me on how I could achive my goal described in the first lines. In particular if I have to copy files to another user's personal folders, what would be the most reliable way to get their paths? Or maybe I am wrong and installing a service into a personal user folder is bad practice at all?
I am aware of the presence of the built-in Local Service account but would like to narrow the service context even more.
The local appdata folder is the problem. If you create a user account the user folders aren't created until the user does an interactive login, and even then in some environments it may be redirected via policy. I am unaware of any reason that local data is better (in a security sense) then the ProgramFiles folder, which is write-restricted to administrators. I'd just install the service binaries to ProgramFiles. In the UI you can collect credentials and use them when the service is installed. A problem with using external credentials is that things like Repair and sometimes patching will fail unless you have the credentials available, having saved them somewhere safe, because otherwise the property values you use will be empty on repair. If localservice works then use it.
It normally doesn't matter what privileges a service has because it usually knows what it's doing. It's only an issue if it calls unknown external code that may try to do something bad, or if it gets asked to do random things such as "run this program" or "copy this file" without doing any internal validation or having a whitelist of what it's allowed to do. So it might be useful to know if there's a specific problem you're trying to address or just following good practices.
I don't think you're being overcautious, service isolation is definitely a good goal. If you can require Win7/2008R2 or later, then you can run the service under a virtual account. There is no password required for virtual accounts, and they don't have the ability to completely wreck the machine like SYSTEM does. You should be able to use it like this:
<ServiceInstall Account="NT SERVICE\$(var.ServiceName)" Name="$(var.ServiceName)".../>
It's actually better for the service executables to be in Program Files, that way the service can't modify its own exe.
When I go to mydomain.example:8080 there is no authorization mechanism by default. I have had look at the configuration area but cannot find anywhere to add a basic username and password
Go to Manage Jenkins > Configure Global Security and select the Enable Security checkbox.
For the basic username/password authentication, I would recommend selecting Jenkins Own User Database for the security realm and then selecting Logged in Users can do anything or a matrix based strategy (in case when you have multiple users with different permissions) for the Authorization.
Assuming you have Manage Jenkins > Configure Global Security > Enable Security and Jenkins Own User Database checked you would go to:
Manage Jenkins > Manage Users > Create User
Try deleting the .jenkins folder from your system which is located ate the below path.
C:\Users\"Your PC Name"\.jenkins
Now download a fresh and a stable version of .war file from official website of jenkins. For eg. 2.1 and follow the steps to install.
You will be able to do via this method
You need to Enable security and set the security realm on the Configure Global Security page (see: Standard Security Setup) and choose the appropriate Authorization method (Security Realm).
Depending on your selection, create the user using appropriate method. Recommended method is to select Jenkins’ own user database and tick Allow users to sign up, hit Save button, then you should be able to create user from the Jenkins interface. Otherwise if you've chosen external database, you need to create the user there (e.g. if it's Unix database, use credentials of existing Linux/Unix users or create a standard user using shell interface).
See also: Creating user in Jenkins via API
If installed as an admin, use:
uname - admin
pw - the passkey that was generated during installation