How to properly authenticate into Jenkins webhooks from Github when LDAP is enabled? - authentication

We have done a fair amount of work and have come pretty close to getting Jenkins to automatically kick off a build when a push is made into Github. However, Github is logging an error from Jenkins when attempting to post to the Github plugin webhook as follows:
Error 401 Either no such user 'CN=Github Account,OU=Jenkins,OU=Applications,DC=mydomain,DC=com' or incorrect password; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece?]
We have LDAP enabled in our environment to allow for active directory logins. An account called "github" has been created on our domain and authorized as a Jenkins user. We are able to manually login to Jenkins by punching in the username and password for this account and it works as expected. The "github" account has been authorized on the project for READ and BUILD directives on the job.
On Github, the push webhook has the url defined as follows:
http://github:password#jenkins.mydomain.com:8080/github-webhook/
We can confirm that the push event effectively triggers the post to the URL, but the response is a 401 with error details as described above. We know the account is valid and the password is correct, but we are stuck because we cannot understand why Jenkins suggests that it is invalid.
We have used the following link, among many others as a guide:
http://fourkitchens.com/blog/2011/09/20/trigger-jenkins-builds-pushing-github
As far as we can tell, the only difference between our configuration and those of others who have posted about their success on blogs and here on Stackoverflow is our use of LDAP authentication.
Does anyone have any guidance to help us overcome this hurdle? Currently, we can successfully run a build manually, so our communication TO Github FROM Jenkins is tip top. But Github back to Jenkins is a frustrating no-go.

This is now working. Here is what went wrong. When configuring the following string, pay careful attention to both the username and password:
http://github:password#jenkins.mydomain.com:8080/github-webhook/
In our case, the password contained special characters that Jenkins was tripping over. Usernames and passwords with special characters must be URL encoded or the authentication will fail. For example, the following password
!test+pw
must be URL encoded as follows:
%21test%2Bpw

Related

Anyone know how to fix the new OAuth2 error when trying to authenticate a PyDrive application?

I don't think this issue is specific to PyDrive, but rather Google OAuth. However, some of the solutions I've seen on stackoverflow don't seem to be transferable over to my PyDrive application, which is just a python script to upload files programmatically to a shared drive. It worked fine 2 months ago but I tried to rerun it today and it's not working. Here is the error I'm getting:
Authorisation Error
Error 400: invalid_request
You can't sign in to this app because it doesn't comply with Google's OAuth 2.0 policy for keeping apps secure.
You can let the app developer know that this app doesn't comply with one or more Google validation rules.
Request Details
The content in this section has been provided by the app developer. This content has not been reviewed or verified by Google.
If you’re the app developer, make sure that these request details comply with Google policies.
redirect_uri: urn:ietf:wg:oauth:2.0:oob
I am using a web application OAuth 2.0 Client ID creds on GCP. All secrets are stored in a local client_secrets.json file.
I run my script, it sends a message to the console that says
Go to the following link in your browser:
https://accounts.google.com/o/oauth2/auth?client_id=blahblahblah.apps.googleusercontent.com&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive&access_type=offline&response_type=code
Enter verification code:
How it used to work: After I click the link above, it returns a code I paste into the console and then its authenticated. FYI: I plan on running this 24/7 on a remote server.
Now: I click the link above and get the error I posted above. I've tried to change the redirect uri to 127.0.0.1 and it does allow me to auth, then I get a code in my URL, but once I copy that and paste it into the console, I get more errors.
Anyone know the solution for this?

cURL: which information is needed to get access token to login to a website?

after successfully getting past the login page using curl in Linux (bash) with two sites that use information from the HTML-form field to accomplish this, I now also want to login to another site with my credentials that is a bit more tricky. I'm new to this and it seems that it works with OAuth so I need an access token first. With my two successfull attempts it was necessary to extract a CSRF token from the HTML code so as to prove I'm not a malicious bot. But now it's completely different and the server thinks I'm a bot (see error messages below).
Can somebody please confirm whether these are the only steps involved for logging in to an OAuth protected site:
a POST request to the server that generates the token (https://name_of_site/api/v1/auth/token)
a GET request to a password-protected part of the website using the access token from step 1
When I try step 1, I get error messages as shown below*. I inspected the website before logging in and afterwards with a browser and copied everything as cURL (bash). In the header fields of the token request I can find two more fields that look like they provide dynamic information:
x-trace-request-id
x-recaptcha-v3
I did some research and found that the request ID stays the same for some interactions that go to and from a server to facilitate identification of the client(?).
And concerning the recaptcha, I know what a recaptcha is, but I did not have to solve any captchas when accessing the site with a browser. So I'm quite unsure about these bits of information.
I strongly assume that I need to send one or both of these headers in the first step to actually get an acess token. But how could I get valid values for these parameters with cURL?
Any help is aprreciated! Please point me in the right direction. I can provide more information if needed, of course.
{"status":"ERROR","statusCode":400,"data":{"message":"Request failed with status code 400","error":"invalid_grant","error_description":"invalid credential","bot-detection-error":"MissingAdditionalAuthToken"}}
This is the error I get when I do not provide x-trace-request-id and x-recaptcha-v3
{"status":"ERROR","statusCode":400,"data":{"message":"Request failed with status code 400","error":"invalid_grant","error_description":"invalid credential","bot-detection-error":"InvalidCaptchaV3Token"}}This is the error I get when I simply use the values as copied from the old request when I used the browser

Login to Sharepoint Online failure

We have a code that logins to Sharepoint Online using :
https://login.microsoftonline.com/extSTS.srf or https://login.microsoftonline.com/RST2.srf, but recently we starting to get authentication failed saying that "Incorrect Username or Password" and after some retries it returns:
"0x80048823 message : AADSTS70002: Error validating credentials. AADSTS50053: You've tried to sign in too many times with an incorrect user ID or password."
While using same username and password to login in the browser works fine, and neither password or username were changed, also code didn't changed. As same code works fine for another Sharepoint tenants. Seems that something changed in the Microsoft login servers, where it's started to not accept user credentials, while web browser login works fine.
Please advise.
Thanks
Microsoft Rep has helped me get this far.
They had us create a "Cloud Only" user. This user was setup as "#" so if your name is bill and your corporate sharepoint site is name is FakeCompany.sharepoint.com then you would have the person as "bill#FakeCompany.onmicrosoft.com"
This user was able to login to https://login.microsoftonline.com/extSTS.srf by just passing username and password.
Our on prem AD users are still having issues, i mentioned this and got the following response.
There is no issue with sync as you are able to login to portal using the same account and password.
The solution you need is documented in https://learn.microsoft.com/en-gb/azure/active-directory/manage-apps/configure-authentication-for-federated-users-portal#enable-direct-authentication-for-legacy-applications
You need to create a home realm discovery (HRD) policy where "AllowCloudPasswordValidation":true.
We have not yet implemented the last solution but the creating of a cloud account may help some of you.
So I think I understand what they are trying to say. There are 2 paths that you are able to authenticate with according to the node-sp-auth example.
"Managed" and "Federated"
"Managed" was the easier version and allowed for you to be able to just provide username and credentials in a soap assertion to login.
Federated is a lot more complicated. You need to first perform a post to Microsoft to validate the user hitting your adfs server. https://adfs.XXXXXXX.com/adfs/services/trust/13/usernamemixed
Then you take the saml:Assertion from that response and put it into the "Token" section of the call you make to https://login.microsoftonline.com/extSTS.srf utilizing the templates from the node-sp-auth.
I have C# code that performs all these steps but I am getting an error
AADSTS70002: Error validating credentials. AADSTS50008: SAML token is invalid. AADSTS50006: Invalid signature. Signature verification failed.
Even though the signature is being generated by Microsoft in their SAML.
node-sp-auth code refrence is OnlineUserCredential.ts file.
If someone can figure out the last mile I can post a comprehensive C# solution.

JIRA CLI Commandline Not Authenticating With Password Federation

I'm having a few problems getting this JIRA commandline to work:
C:\tools\atlassian-cli-7.8.0>jira.bat --debug --verbose --options
basicAuthentication --server "https://jira01.COMPANY.com" --user
FIRST.LAST#COMPANY.COM --password PASSWORD --action getServerInfo
It connects to the JIRA server, but gives this error:
org.swift.common.cli.CliClient$RemoteDisallowedException: User
'FIRST.LAST#COMPANY.COM' is not allowed to log in at this point in
time perhaps due to CAPTCHA requirements or too many failed login
requests.
This error always occurs despite the fact:
JIRA Web > Profile > Username is what I'm using to log in.
JIRA Web >
Profile > Groups is jira-software-users
The password provided to the
commandline is indeed the one that works when I login via the web.
I
have tried this both with and without --options basicAuthentication
This occurs regardless of how many times I successfully log out / log
in to the JIRA web UI.
Whenever I go to JIRA Web > Profile > Change
Password, it says: "Too many incorrect login attempts: Please log out
and log in again to access this function." (This also occurs
regardless of how many times I successfully log out / log in to the
JIRA web UI.)
A CAPTCHA is never shown on the JIRA Web UI's login.
NOTE: When we login to JIRA web ui, our company appears to defer to
federated authentication via "https://login.microsoftonline.com" into
which we provide the credentials we're providing the script, which
then takes us into JIRA.
Questions:
How to get the commandline tool / jira server to accept the same credentials the jira web ui does?
Is this a permissions issue or something involving the password federation?
Suggestions for how to get this to work?
How to get it to actually clear the "too many incorrect logins" issue?
Cheers & Thanks!
-Roberto
Full trace of command is:
URL requested:
https://jira01.COMPANY.com/rest/org.swift.jira.cli/latest/validatelicense
Request type: GET Content type: application/json options:
basicauthentication URL requested:
https://jira01.COMPANY.com/rest/auth/1/session Request type: POST
Content type: application/json Using basic authentication. Request
property X-Atlassian-Token, value: [no-check] Request property
Content-Language, value: [en-US] Request property Content-Type, value:
[application/json] json: {} Problem determination - response: 403:
null Problem determination - response url:
https://jira01.COMPANY.com/rest/auth/1/session Problem determination -
request url: https://jira01.COMPANY.com/rest/auth/1/session Problem
determination - response data:
Forbidden (403)
...
Remote error: User 'FIRST.LAST#COMPANY.COM' is not allowed to log in
at this point in time perhaps due to CAPTCHA requirements or too many
failed login requests. Go to the user interface and login to clear the
problem.
org.swift.common.cli.CliClient$RemoteDisallowedException: User
'FIRST.LAST#COMPANY.com' is not allowed to log in at this point in
time perhaps due to CAPTCHA requirements or too many failed login
requests. Go to the user interface and login to clear the problem. at
org.swift.jira.cli.helpers.AuthenticationHelper.login(AuthenticationHelper.java:196)
at
org.swift.jira.cli.helpers.AuthenticationHelper.login(AuthenticationHelper.java:157)
at
org.swift.common.cli.helpers.DefaultAuthenticationHelper.handleCookies(DefaultAuthenticationHelper.java:124)
at
org.swift.jira.cli.JiraClient.getAuthenticationHelper(JiraClient.java:185)
at
org.swift.jira.cli.JiraClient.getAuthenticationHelper(JiraClient.java:107)
at
org.swift.common.cli.helpers.DefaultRequestHelper.setConnectionProperties(DefaultRequestHelper.java:1043)
at
org.swift.common.cli.helpers.DefaultRequestHelper.setConnectionProperties(DefaultRequestHelper.java:1030)
at
org.swift.common.cli.helpers.DefaultRequestHelper.makeRequestWithUrlConnection(DefaultRequestHelper.java:724)
at
org.swift.common.cli.helpers.DefaultRequestHelper.makeUrlRequest(DefaultRequestHelper.java:690)
at
org.swift.common.cli.helpers.DefaultRequestHelper.makeRequest(DefaultRequestHelper.java:660)
at
org.swift.common.cli.helpers.DefaultRequestHelper.makeStandardRequest(DefaultRequestHelper.java:648)
at
org.swift.common.cli.helpers.AppfireRequestHelper.getServerInfo(AppfireRequestHelper.java:118)
at
org.swift.jira.cli.JiraClient.getRemoteServerInfo(JiraClient.java:2493)
at org.swift.jira.cli.JiraClient.getServerInfo(JiraClient.java:2455)
at org.swift.jira.cli.JiraClient.handleRequest(JiraClient.java:840) at
org.swift.common.cli.DefaultRemoteClient.process(DefaultRemoteClient.java:729)
at org.swift.common.cli.CliClient.doWork(CliClient.java:674) at
org.swift.common.cli.CliClient.doWork(CliClient.java:631) at
org.swift.jira.cli.JiraClient.main(JiraClient.java:166)
I managed to get this working by creating an API token and using that as the password. You can create an API token by visiting the https://id.atlassian.com/ site and selecting the API tokens on the left pane.
I hope this helps.

Gitlab login LDAP user without e-mail

In my organization, some users don't have an e-mail address. At the e-mail field in ActiveDirectory, they have a fake (malformed) e-mail address, something like "user.name#xx".
When these users try to login into Gitlab, they get the following error:
'Could not authorize you from LDAP because "Validation failed: email is invalid, email is invalid".'
Is there any configuration to ignore email adress checking with LDAP?
The issue 6230 has been tracking this:
The mail validation on user model is performed by validation here: app/models/user.rb.
I think you can configure your own regexp here: config/initializers/devise.rb.
However, the official statement is:
Disabling validation is not something that will be done on GitLab side. This can lead to inconsistencies in the database and could cause a plethora of issues.
I suggest you :
either fix your LDAP
or have allow_username_or_email_login setting enabled: https://github.com/gitlabhq/gitlabhq/blob/master/config/gitlab.yml.example#L130
This is issue is a support question so I will point you to the contributing guide and close it.
Not directly with GitLab itself, because that error message is the result of an omniauth callback: see config/locales/devise.en.yml:
omniauth_callbacks:
success: 'Successfully authorized from %{kind} account.'
failure: 'Could not authorize you from %{kind} because "%{reason}".'
Yet, the Rodrigo Carvalho reports in the comments:
I actually discovered this is a Gitlab behaviour.
I changed the "/lib/gitlab/oauth/user.rb" (Gitlab code) to append a ".com" in the end of the invalid email address and it worked.