WSO2 Identity Server SCIM Authorization issue - wso2

Having WSO2 IS 5.0.0.SP1 backed by PostgreSQL there is another application reading user information using the SCIM service (filter=userNameEq...)
All works but after certain time the service returns "User is not authorized.." response with a single ERROR level log line. Since that moment all subsequent calls fail with "404 User is not authorized". Even when I log in using the admin account I have no access rights. This state takes for a few minutes and then all seems working again.
We traced the response message to the SCIM service implementation where the authorization is checked. However we are unable to find the root cause of the issue (suspecting some exception is qietly dropped, cache cleanup cleans more than it should, ...)
Any hint / idea is appreciated.
Carpe diem
Gabriel

This seems to be authorization issue. If after trying 3 fail login attempt user locked 0-minutes(Most user used 05 minutes). This is default settings of fresh WSO2 IS pack. After the configured locked-time user unlocked. Then the user have a login with valid credentials. If you need, you can change the login attempt,locked time.Please check [IS_HOME]/repository/conf/security/identity-mgt.properties file. It's having the all configuration.

Issue is resolved (or - reason is identified in another system). In the AD tree one of the domain controllers is external (cloud) and unable to authenticate the technical (wso2) datastore user. When the AD node hostname is resolved to the cloud node, then ldapsearch is unable to return any groups from a sub-domain of the cloud based domain controller (interesting - it doesn't fail).

Related

Using Kerberos request type instead of NTLM in power-bi report server

I'm having a server with power-bi reporting service installed and configured on it, and from my front-end that hosts the application, i've got angular 7 with proper power-bi components installed.
Since the report is on the server and it needs authentication to login, i get a user and password fill-in prompt in my website whenever i try to access this report, and after logging in, i can see the data of my report.
I'm wondering how to use Kerberos authentication so that i can set-up that username and password to login automatically without asking the user to enter them every time.
What i've done so far :
I've made and set a few SPN in my active directory, made a user in Active Directory Users and Computer and in it's Delegation tab, i've set it to Use any authentication protocol and added MSOLAPDisco and MSOLAPSvc.3 to it. i've added the user account credentials that i've made to service account and execution account in power bi Report server then i modified the rsreportserver config file to use the RSNegotiate before NTLM.
After trying to solve the issue with the mentioned above methods, i still get a NTLM method in network monitor which is installed in the Active Directory.
Any suggestions how to solve this issue? Thanks in advance.

WSO2 MB an exception after admin psw change

I tried to make a production set up (WSO2 MB 3.1.0 and WSO2 ESB 4.9.0) on the same VM.
in order to secure my production environment I changed the default admin psw for the admin user to more secure one. At the same time I created a new MB user (ESB) which I used as "a technical user" in ESB jndi.properties
when I restarted my server I started receiving the following exception in the ESB which tried to connect to the MB:
[2016-10-07 16:47:31,427] ERROR - AMQStateManager Notifying Waiters([org.wso2.andes.client.state.StateWaiter#654a6148]) for error:not allowed
[2016-10-07 16:47:31,427] INFO - AMQConnection Unable to connect to broker at tcp://localhost:5673
org.wso2.andes.client.AMQAuthenticationException: not allowed [error code 530: not allowed]
at org.wso2.andes.client.handler.ConnectionCloseMethodHandler.methodReceived(ConnectionCloseMethodHandler.java:79)
at org.wso2.andes.client.handler.ClientMethodDispatcherImpl.dispatchConnectionClose(ClientMethodDispatcherImpl.java:192)
at org.wso2.andes.framing.amqp_0_91.ConnectionCloseBodyImpl.execute(ConnectionCloseBodyImpl.java:140)
at org.wso2.andes.client.state.AMQStateManager.methodReceived(AMQStateManager.java:111)
at org.wso2.andes.client.protocol.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:517)
I back-traced the problem to the change of the ADMIN psw. When I set it back to the default ADMIN:ADMIN all is working again fine.
any idea why? apparently the psw is not changed on all the places
I followed this article https://docs.wso2.com/display/MB220/Changing+User+Passwords
my configuration xmls does not contain the admin psw however.
thank you very much in advance.
AFAIU, Following are the steps you have followed.
Changed MB default username/password.
Created new user("a technical user") in MB and add these username/password in ESB "jndi.properties" file.
Restarted servers and ESB start throwing auth exceptions.
Things would have gone wrong(at least what I can think of) is as follows :
Somehow you have entered spaces in middle of the username "a technical user"(even it's validated in MB management console)
Solution : Don't use spaces in of usernames.
Even you have created a new user in MB(and added it correctly in jndi.properties file in ESB) you haven't assigned a role which have permission to subscribe to a topic/queue. (This is what most likely you have messed up :))
If you haven't assigned a role which has subscribe permissions to queues/topics ESB won't be able to subscribe with given credentials during transport startup which leads to authentication exceptions.
MB has a role based permission model and if you haven't assigned a user to a role with sufficient permissions user won't be able to authenticate to MB. To verify this theory you can assign "admin" role to newly created user from MB management console under("
Home > Configure > Accounts & Credentials > Users and Roles > Users") and restart ESB server.
Please go through following documentations[1] carefully for more permission/users/user roles related information.
[1]
https://docs.wso2.com/display/MB310/Managing+Queues
https://docs.wso2.com/display/MB310/Configuring+Users
https://docs.wso2.com/display/MB310/Role-Based+Permissions

WSO2 Identity Server 5.0.0 fails to return user claims in SAMLResponse for user from secondary user store

I have this problem when using SAML SSO authentication. I have successfully set up WSO2IS 5.0.0 Identity server, I also succeeded setting up (at least I hope so) secondary user store. I used JDBCUserStoreManager implementation. I have set this store as DOMAIN. This user store works nice, at least I think it does. Because it is storing user attributes into its tables (USER_ATTRIBUTES) and those attributes are read by WSO2IS administration ...
https://localhost:9443/carbon/userprofile/edit.jsp?username=DOMAIN/demo_jbu&profile=default&fromUserMgt=true
Users are identified as DOMAIN\username so when I want to log in user from this DOMAIN, request goes to my AUTHENTICATOR implementation so I can manage authentication for users from this domain.
What is strange is, that if I use WSO2IS administration pages, I can set and read users's attributes well. And if I use SAML SSO authentication (have already set up service provider & claim mappings) for users from PRIMARY domain, everything goes fine and calling SP gets all attributes - mapped in WSO2IS administration here:
https://localhost:9443/carbon/application/configure-service-provider.jsp
If I use SAML SSO authentication, but I want to log user from my DOMAIN, SP doesn't get anything.
I can override this behavior in DefaultResponseBuilder, I can put into SAMLResponse anything I want, but I don't feel this approach is OK. Can anyone tell me, where to look for an error? What may be wrong? Where should I start looking for problems? I have already tried to debug it, and it seems it (SAML SSO/AUTHENTICATOR) doesn't find any claim for DOMAIN user.
Thank you in advance.
Josef
I think this is bug in Identity Server 5.0.0. When you are using SAML2 SSO, user can login to Identity Server with both username with domain name and username without domain name. Basically
bob and foo.com/bob must both works and returns the bob user's attributes from foo.com user store. However there is issue with IS 5.0.0, if secondary user store user login without domain name, Identity Server does not returns the user attributes. But, please try to login with foo.com/bob , Then it would return the user's attributes.
You can find the public jira. It contains source diff. It must be a simple fix and you even can compile the source and add fix in to the Identity Server.

Configuring Single Sign-On Across Stratos

I have a situation where I need to setup a standalone version of wso2 Identity Server and have that act as the SSO provider into all of the products in Stratos.
Currently I have Stratos Identity Server configured so that I can login via the standalone Identity Server, using admin.
However, if I use another user I either
get a "Authorization Failure"
or cannot login.
First Question
1) I have the same user created in both Identity Server (that is not admin). Why would I get the "Authorization Failure" ?
Second Question
2) Why is it I can not even get to the "Authorization Failure" problem if I have a user created with username in format of user#domain.com ?
UPDATE:
I figured out that if I remove the property tags in user-mgt.xml that reference the usernames with regular expressions I am able to create usernames in the format of name#domain.com. But I am still unable to use that username to login, the error log says that the account has not been activated.
I also created two instances of wso2 identity server and configured them in such a way to test being able to use one to login to the other. I was able to do this by making sure that the same username and password was in both servers list of users. This way I do not get the "Authorization Failure"
The answers I came up with.
1. I need to have the same username and password in each Identity Server.
2. I cannot have format name#domain.com unless I have Multi-tenancy configured. Otherwise wso2 will try to find the ACTIVATE field in the Tenant table and not find it.
UPDATE: I got this installed and configured and it turned out that I now get another error about
Issuer details are not valid. Issuer details should be registered in advance
So my answer turned out not to to be valid.
I wonder why I get this new login failure?
UPDATE RESOLVED!!:
I resolved this problem by downloading just the wso2 stratos IS 1.5.2 package. I installed it. Configured with same configuration I was using before. Now I can login without problems across domains.

Using DefaultCredentials and DefaultNetworkCredentials

We're having a hard time figuring how these credentials objects work. In fact, they may not work how we expected them to work. Here's an explanation of the current issue.
We got 2 servers that needs to talk with each other through webservices. The first one (let's call it Server01) has a Windows Service running as the NetworkService account. The other one Server02 has ReportingServices running with IIS 6.0. The Windows Service on Server01 is trying to use the Server02 ReportingServices WebService to generate reports and send them by email.
So, here's what we tried so far.
Setting the credentials at runtime (This works perfectly fine):
rs.Credentials = new NetworkCredentials("user", "pass", "domain");
Now, if we could use a generic user all would be fine, however... we are not allowed to. So, we are trying to use the DefaultCredetials or DefaultNetworkCredentials and pass it to the RS Webservice:
rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials
Or:
rs.Credentials = System.Net.CredentialCache.DefaultCredentials
Either way won't work. We're always getting 401 Unauthrorized from IIS. Now, what we know is that if we want to give access to a resource logged as NetworkService, we need to grant it to DOMAIN\MachineName$ (http://msdn.microsoft.com/en-us/library/ms998320.aspx):
Granting Access to a Remote SQL Server
If you are accessing a database on another server in the same domain (or in a trusted domain), the Network Service account's network credentials are used to authenticate to the database. The Network Service account's credentials are of the form DomainName\AspNetServer$, where DomainName is the domain of the ASP.NET server and AspNetServer is your Web server name.
For example, if your ASP.NET application runs on a server named SVR1 in the domain CONTOSO, the SQL Server sees a database access request from CONTOSO\SVR1$.
We assumed that granting access the same way with IIS would work. However, it does not. Or at least, something is not set properly for it to authenticate correctly.
So, here are some questions:
We've read about "Impersonating Users" somewhere, do we need to set this somewhere in the Windows Service ?
Is it possible to grant access to the NetworkService built-in account to a remote IIS server ?
Thanks for reading!
All details you need are included in this very old article
In short, when you find it confusing to troubleshoot issues like this, you should first review the technical details behind ASP.NET impersonation carefully.
Here are some things you could check out:
- set an SPN (Service Principal Name) for the reporting service; you can find good examples in google;
- Allow delegation (ClientCredentials.Windows.AllowImpersonationLevel)
Is the problem that you're failing to authenticate to IIS, or failing to authenticate to SSRS? The DOMAIN\MachineName$ account may need to be granted permission in SSRS to run the report you're trying to automate.
SSRS usually does a pretty good job of getting IIS configured correctly, so you shouldn't need to mess with those settings. I double-checked my installation (which is SSRS 2005, things may have worked differently in SSRS 2000 and you didn't say which version you're running), and it's set to use Windows authentication and has impersonation enabled. That means IIS should basically just be authenticating your credentials (validating a correct username/password), not authorizing (determining whether that user has permission to run the report in question). IIS then passes the credentials on to SSRS, which has its own settings for determining what accounts have permission to view reports.
Also, you can automate sending reports on a scheduled basis directly in SSRS, so you may not need the Windows service at all if your scheduling is fairly basic (i.e., daily, weekly, etc.).