Domain glassfish requires authentication with the realm 'dolmen' - glassfish

In my work I give support to users, and the following problem has been sent to me.
Logs Jenkins: (Automated tests that run in the night)
[HttpAuthenticationRequestFilter$UPDCredentialsProvider] Domain
request authentication with the realm 'dolmen'
Logs Server:
23/01/2018 01:28:25.637 [http-thread-pool-8080(15)] WARN java.util.logging.Logger.doLog WEB9102: Web Login Failed:
com.sun.enterprise.security.auth.login.common.LoginException: Login failed: Security Exception
23/01/2018 01:28:25.646 [http-thread-pool-8080(29)] ERROR java.util.logging.Logger.doLog jdbcrealm.invaliduserreason
Via asadmin I've checked that the realm dolmen exists
asadmin> list-auth-realms
Authentication failed with password from login store: /root/.asadminpass
Enter admin password for user "admin">
admin-realm
file
certificate
dolmen
pnf-realm
Command list-auth-realms executed successfully.
asadmin>
What could be the problem?

UPDATE 1)
I was able to reproduce the error in SOAPUI. During the call to the web service, I noticed that if I change a letter in the login user or password, I can see the error message : " request authentication with the realm 'dolmen'"
Log SOAPUI:
But as you can see, in the image "Log SOAPUI:" I also have a HTTP 401.
In SoapUI Preferences, I notice that the option "Authenticate Preemptively" was disable. After enable the option "Authenticate Preemptively" I was able to finish a test in my local machine without error.
In the machine where Jenkins is installed (Where the Automated tests run in the night), I notice that the file soapui-preferences.xml does not exist. So maybe the solution for the problem is here.
I'm waiting for a time frame to be able to test without impacting testers.
I will keep you posted.
UPDATE 2)
To get rid of this problem I've rebuild my glassfish domain.

Related

Docker API logs JWT issue

I am using Docker to run containers for an app that uses Angular, Identity Server, and an API(using a Compose.yml file to run them all together).
The API is responsible for returning database info, based on the user logged in through Identity Server. Locally, the API returns the user info after login without any issues. However, when I use Docker to run the app, the user can login but not have their db info returned to the angular page. I checked the logs for the API container, and am receiving the following errors:
fail: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[3]
fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
So it appears to me that there is an issue with the API receiving the token. I only see these error messages after I login through ID server. The ID server container logs do not display any errors before or after I login.
Can someone help me resolve this issue?

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.

fail to authenticate after deployment

I have a web application using glassfish and form authentication (j_security_check). All the passwords and usernames are stored in a javaDB (derby). I was able to log into the system while developing on the localhost and now that I deployed the app to AWS whenever I try to log in with a user (I have checked that the user actually exists in the DB), I always get the same error (that i normally get when entering wrong details) i.e. WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed.
Any ideas what it might be? I don't even know what info to provide since the issue doesn't even throw an exception or something. thanks

REST Client step in Pentaho DI (Kettle) says I do not have permission to API

I am using version 5.1 of Pentaho DI (Kettle) and am having an issue with the "Rest Client" step. The step executes properly and successfully, but the result says I do not have permission to use the API. I have confirmed in another tool that I do have permission. I have entered my login information on the Authentication tab and have built my URL to include my token.
What am I missing?
ADDITIONAL INFO: I am having the same issue with the "HTTP Post" step. The status being returned from the API is 403.
403 is "Forbidden". Check that you have the correct credentials to access the webservice. The request went through and the server rejected sending the response because username/password are not correct or otherwise the user does not have permissions for that request. Can you see the response correctly in a browser when you enter EXACTLY the same credentials? To avoid active browser sessions masking the real issue I'd test it on incognito/private browsing mode on the browser.

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

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