My problem is that the oAuth gets denied on our test server but it works on our live and development (local) servers.
Is there something specific what I have to configure to make it work on antoher server?
I compared the platform folder with test and live, both are identical.
I created same oAuth logins on both servers, didn't work.
I tried to login through the ip, to avoid apache, didn't helped.
Now I am kind of lost where to look next.
To test my login I use Swagger or Postman with this url: https://test.shop/authorizationserver/oauth/token with Basic Authorization.
The reponse is: {"error":"invalid_client","error_description":"Bad client credentials"} but it is wrong.
This is the configuration for the user:
I had besides this problem, an equal one on the live system. Our apache removed the Authorization from the header to get the Backoffice working, which is protected through the htaccess. When I was researching this problem, I got the same error as this one. Now everything works fine on live. I corrected the same thing on test, tried even uninstall apache, but the login is still not working.
You need configure oAuthClient for SmartEdit by running following Impex:
INSERT_UPDATE OAuthClientDetails;clientId[unique=true];resourceIds;scope[mode=append];authorizedGrantTypes;accessTokenValiditySeconds;authorities;clientSecret;;smartedit;hybris;basic,permissionswebservices,previewwebservices;password,client_credentials;3600;;;
For details, please see:
Configuring oAuthClient for SmartEdit
Can you please check if the configurations are similar? If yes then there is something env specific and needs to be debugged individually.
We fixed the problem by pasting the correct "OAuth client secret" into the "Password" and "Verify password" field. This was initialized via impex with an old value (but not visible to the user in the dialog as seen in the lower screen).
Related
I am trying to record an internal website for which i need to enter credentials that is not same as the windows credential. Later on the same test needs to be run for more than one user. i know how to use the csv file to pass the parameters - username and password.
For Windows Authentication i have added Authorization manager.
From Fiddler i checked it was NTLM authentication(though i am not sure yet) and i did enter the values for NTLM authentication in Authorization Manager.
Now when i try and record the internal website - i cannot even go to homepage after the windows credentials, it keeps on spinning.
When i check the Authorization Manager, i find an extra line added for kerberos Authentication as shown in Picture:
My query here is:
1)why is it recording it as kerberos
2)where is it saving the username and password
3)why is it not loading the website- always keeps spinning and i have to stop it
4)I have tried Kerberos settings and then record, but its not working either , could it be i am using the wrong values in the kerb5.conf file , how do i debug.
Kind of stuck at the moment.
Thanks for help!
If you're uncertain what authentication is being used under the hood - just ask around, application developers or network administrators should be aware of the external authentication scheme. You can also try using a 3rd-party tool like Kerberos Authentication Tester
I don't think you can record and replay Windows authentication so it makes sense to start recording some time after the login screen as long as you can login using JMeter
Looking into JMeter source
// if HEADER_AUTHORIZATION contains "Basic"
// then set Mechanism.BASIC_DIGEST, otherwise Mechanism.KERBEROS
In case of Kerberos credentials are saved directly in the HTTP Authorization Manager in form of ${AUTH_LOGIN} and ${AUTH_PASSWORD}, real credentials are not stored anywhere
Most probably your application doesn't receive valid authentication context therefore it cannot proceed
Add sun.security.krb5.debug=true line to system.properties file (lives in "bin" folder of your JMeter installation), JMeter restart will be required to pick the property up.
More information:
Windows Authentication with Apache JMeter
JAAS and Java GSS-API Tutorials
Very strange issue I am facing from past few days. I am just able to login to any application on my domino server using "Mozilla Firefox". If I use any other browser (Chrome, IE), it just stays on the login page with absolutely no information, everytime I login in it again shows back the login page with no error message at all. Its quite strange since its working perfectly fine on Firefox.
I am not sure, but I somehow feel that it has something to do with the configuration. Would really appreciate if someone can guide me here.
Edit 2:
Selecting Single Server, does work, that was the simplest solution; as of now we do not need "Multiple Server".
However, we do not use any other "Internet Sites", I tried to remove the organization field, however, that lead me to "An R5 web SSO configuration already exists", which in turn lead me to here. However, I am able to move further here with "Multiple Servers".
Edit 1: Based on the answers, here are the things I tried. Please find below the snapshot of each of it for better understanding..
LTPA Token Configuration
Server Configuration for LTPA Token
Network tab - before login
Network tab - after login
Console shows nothing before or after login, neither does the server log files. Also, I am able to access the names.nsf database with absolutely no problem. Lastly, I try to access a database with no anonymous access and hence get redirected to the login page (however, as question mentions, it just stays in loop)
Ok, you may need to provide a little more information.
Are you doing a "normal" login using domcfg and a "...&login" url? Or are you trying to open a design element in a database that has no access to "anonymous" and thus redirects to the login?
You can easily check that "standard" login by opening the url: http://yourserver.com/names.nsf?login. Does it behave differently in the browsers? If not then your server setup etc. is Ok. Then you have to look at the solution that tries to log you in.
Your first place to check is in the browser's console. Are there any errors in there? E.g. some client side Javascript that stops running? Check the network tab when you inspect the console/developer tools. Does it send the right requests?
Another step is to check the console/log files on the server. If you have grown your own solution then you may want to add some simple print statements to prove that it sends what you think.
Finally, you can use a network sniffer (like wireshark) to see exactly what is sent between your browser and the server.
/John
A login- page that reloads itself after every login without a message like "Wrong username or password" or similar normally happens if the session authentication for the server is configured as Multiple Servers (SSO) (Found in Server document on Internet protocols-Domino Web Server, if Internet Sites are Disabled or in Internet Site document, if they are enabled).
In that case an LTPAToken has to be configured as well, and this token has to have a configured domain name. Whenever you try to access a server with SSO enabled using a hostname without domain or with a different domain, then exactly this will happen: Login- Page reappears after every try to login.
Example:
if the servername is myserver with ip 10.10.10.1 and the LTPAToken is configured for ".mydomain.com", then the only valid URL for login is:
hxxp://myserver.mydomain.com
Trying hxxp://myserver or hxxp://10.10.10.1 will result in exactly the described behaviour.
It is important to know, where to look for the "right" SSO- Configuration document.
If the server is configured to use "Internet Site documents" (Server- document, Basics- Tab, Load Internet configurations from Server\Internet Sites documents enabled) , then the SSO- document needs the field "Organization" to be filled. In that case you will find it in the Web\Internet Sites- View of the domino directory.
If Internet Sites are disabled, then the Field "Organization" has to be empty. In that case you find the SSO- document in the Web\Configurations view.
There is an application that we are using it both on XPiNC and browsers.
Before you can access the application, you must log-in with your user.id from lotus notes. The problem is there are several login msgboxes ( where you must again log in with your username and passwords ) saying:
The server says /xsp/.ibmxspres/dojoroot-1.8.1/dojo.
or
The server says /xsp/.ibmxspres/.mini/dojo/.en-us.
or
The server says /xsp/.ibmxspres/.mini/css.
or
The server says /xsp/.ibmxspres/.extlib/icons.
and so on. Even when I just hit F5 when I'm logged on in application ( there is, also, a computed field which displays the username ) those type of messages are being displayed.
What should I do as a developer? Or there must be some settings at the server?
I have the following ACL rights:
ACL: User type: Person and Access: Manager.
Effective access: all the checkboxes are checked except Full Access Administrator
Thanks for your time!
Ok, this should be straight out of the box ;-)
What I find strange is that the ressources you seem to be asked for access to use are some of the "built in" ressources (Dojo, css, etc.) in XPages...???
So first thing is really to test that this has nothing to do with your application:
Create a new application
Set a proper ACL that will force you to log in (Default reader or higher, a person called "Anonymous" no access)
Create a simple XPage and open it from the browser
What happens?
If everything works, then you need to add some elements that use the ressources (css, Dojo, etc.). Then what happens?
I guess you will see the same problems... If so, you need to have a look at the way you have set up your server for web access. Are you using internet sites? Do you use basic or session based authentication?
What does the ACL of your application look like?
What you experience could be caused by "realms" i.e. the "path" to which you log in. A simple example:
If you are required to log in to access the ressource /path/db.nsf/view/doc1?openDocument then your realm will be "/path/db.nsf/view/" - if then you try to create a document using /path/db.nsf/newDoc.xsp then you could be asked for access to the realm "/path/db.nsf/".
I must admit that I haven't seen these issues for quite a while - but that may be due to the fact that I control access to the database as a whole - if users need access to something inside the database I implement it using "public access". But first, let us hear a little more about your findings before we chase it as a realm issue ;-)
EDIT:
Ok, so you are using basic authentication. There are lots of good reasons to use session based authentication instead. However, that does not explain your problem. What OS are you using? An OS with file access in the file structure? Could it be that the user running Domino does not have access to the ressources? Have any (file) restrictions to these directories been set up? You really should not be prompted to login for these ressources....
Did you try another "new" application?
/John
Switch to session based authentication. The multiple prompts point to BASIC where you can't logout unless you close the browser
I configured my Jenkins server to only use HTTPS and enabled security.
As well I don't like anybody who's not logged on to see the Dashboard (even if it would be empty). Here for I disabled the 'read' access for 'anonymous'.
So far all this works exactly to my likings :)
But wanting to add some build notification functionality to remote clients by e.g. using something like 'CCtray' I run into trouble. The access to the https://<SERVER>/cc.xml now only works for logged in users.
Where I would have liked to be able to get those notifications for 'anonymous'.
Probably combining these wishes is kind of contradictory - I suppose?
Maybe someone has a better idea which could match my likings?
Possibly any other notification tool which can be used???
For the Mercurial hook triggering the sw-builds I can use a construction like
curl --cacert <CERTIFICATE> https://<USER>:<PASSWORD>#<SERVER>/job/MyPROJECT/build?delay=0sec
But a similar approach for the URL in CCtray doesn't seem to work.
I've just started using the cctray Jenkins transport extension. Early days, but it seems to work as advertised and is connecting to our secure server perfectly happily.
Currently, the only significant limitation seems to be that if your password expires there's no way to re-enter your credentials.
For Jenkins servers without anonymous access, you can use Catlight build notification tool. You can provide access token or username/password to authenticate to your server.
I you have a self-signed ssl certificate, make sure that you add it to trusted by OS. That way, most applications will recognize it and connect to server without warnings.
Adding to #MrBlueSky 's answer, you can avoid the password expiration hassle; simply use a Jenkins-issued API Token instead of your password.
Log into Jenkins
Click your username (in the upper right corner)
Click Configure (in the left navbar)
Click Show API Token
Use this token in place of your password when setting up the Jenkins Transport settings
I am trying to test a webpage using Nessus. I have tested all the stuff about the Server. But now I want to proceed by login to the webpage and test all possible pages behind the login form. But I couldn't achieve it. I gave all(text, password and hidden fields) the form fields' values including the ticket generated by Central Authentication System. But nothing happens. Either there isn't any security issue behind the login page ( :P ), or I couldn't login to the page (100% possibility :D ). For extra info:
These are login fields. ;)
username=
&password=
<=_c0C1F5872-F217-B20F-6D86-AA3AA1C1262E_kC7BEB4F7-5216-53EB-2F9A-7FDDFE01D145
&_eventId=submit
&submit=Login
Is there anyone who used Nessus and know how to solve this problem? And is there anyone who knows how to import Cookies to Nessus?
Thanks in advance. ;)
I had similar problems; can't speak for you, but sounds like you have about as much website knowledge as I do (which ain't much!) - no offense intended. In my case I'm not sure I'm understanding the most most basic structural elements of the website, such as what URL to point the scan at, and then concatenating that correctly with the login pages in the policy. I'm far better at the network and infrastructure penetration testing :D
I did a search in a search engine for "Nessus HTTP cookie import", and found that Tenable discussed this on their podcast, episode 14:
http://blog.tenablesecurity.com/2009/11/tenable-network-security-podcast---episode-14.html
If you look at the "Stories" note on the above web page, there's a hint to use the "Export Cookies" Firefox add-on. The add-on has some guidance, but essentially:
Install the add-on to your browser (I'm using the OWASP Mantra browser; I urge you to look at it)
Restart your browser
Login into the subject website and authenticate
From the Tools menu, go for "Export Cookies"
Save to file, and point your Nessus scan policy at that file
NOTE: I'm still trying this now, but thought I'd post the possibility anyway in case I forget - I will update this thread with a confirm or deny shortly.
Best of luck!
UPDATE: Well, it didn't work for me on first attempt. I'm confirming I don't have any conflicting or superseding settings in the policy, but if that doesn't work it's on to Tenable Support, I fear...
According to the documentation, besides importing cookies, the other way to do it (currently at 7.0) is:
Create new scan
Web Application Tests
Credentials:
which are filled out like these (taken from documentation):
Username: Login user’s name.
Password: Password of the user specified.
Login page: The absolute path to the login page of the application, e.g., /login.html
Login submission page: The action parameter for the form method. For example, the login form for: <form method="POST" name="auth_form" action="/login.php"> would be: /login.php
Login parameters: Specify the authentication parameters (e.g., login=%USER%&password=%PASS%). If the keywords %USER% and %PASS% are used, they will be substituted with values supplied on the Login configurations drop-down menu. This field can be used to provide
more than two parameters if required (e.g., a group name or some other piece of information is required for the authentication process).
Check authentication on page: The absolute path of a protected web page that requires authentication, to better assist Nessus in determining authentication status, e.g., /admin.html.
Regex to verify successful authentication: A regex pattern to look for on the login page. Simply receiving a 200 response code is not always sufficient to determine session state. Nessus can attempt to match a given string such as Authentication successful
However, looking at the reports, in my case, it couldn't authenticate for some reason