I have two keycloak servers running on Docker containers locally on my machine. One on port 8080 and the other one on 8888. What I am trying to do is to connect the one with port 8080 to the one with 8888. I want to do that because I want to federate users. This scenario should be a test for a much larger scenario where I want to connect multiple Keycloak servers to one main keycloak servers.
This main keycloak server should be the entry point for all authentication requests. I am currently trying to solve this problem by setting up User Federation on the main keycloak server (Port 8888) using ldap. The following picture shows my configuration:
As you can see, when testing the connection url, it succeeds. However when trying to import users or even when clicking on "Test authentication", it just goes into an endless process which fails with "LDAP Query Failed". I suspect that something is wrong with the credentials (Users DN, Bind DN and Bind Credentials).
I did not found out how keycloak's ldap structure looks like, maybe some of you can help me configure this correctly. The Bind DN I tried is called "remote" (Bind Credentials is same as username), because I thought this must be the default admin account that is created when setting up Keycloak. Because the authentication fails, I suspect that this is not the right way to configure this whole scenario.
I hope I described the problem well and someone of you can help me out on this. Maybe you also have the correct page in the documentation for me to read about that?
Have a great day & Thank you kindly in advance!
Related
I'm new on the world of load balancing...
I heard about HAProxy and I wonder if I can achieve this objective (not found yet over searches already done):
HAProxy receive a MQTT/HTTP connection with basic authentication
(login-password) or token based
HAProxy checks credentials from a Database (or
LDAP)
HAProxy manage the access depending on the authenticated User.
--> all of user/credential and ACL should be stored in Database.
Is this possible? Is there in HAProxy a system of custom plugin/add-on to enhance its behavior ?
I found things about settings list of ACL directly in the configuration with already existing list of login/password (but not dynamically even if cached after)
Thanks a lot for your ideas.
I think this is only supported in Enterprise Haproxy:
The HAProxy Single Sign-On solution [...] is also compatible with Microsoft Active Directory or OpenLDAP servers.
https://www.haproxy.com/documentation/hapee/1-8r1/security/using-sso/
The only plugin I found is a http request check to see if user is authenticated on an arbitrary endpoint:
https://github.com/TimWolla/haproxy-auth-request
But it requires a specialized web app responding the requests for that.
I want to configure LDAP over SSL. I know how to configure it. I am going to use this LDAP server to authenticate user at time of logging in my web site. But In case if any error/exception that may occur due to LDAP over SSL ( like certificate expired, empty certificate store ), I DONT WANT USER WILL BE PREVENTED TO LOGIN JUST BECAUSE OF MERE SSL exception. What I want to do in that case is to use LDAP WITHOUT SSL. Can I configure one LDAP server to run with and without SSL at different port simultenously? Or I must use two different LDAP server (and so machine) and arrange some fail over mechanism that if one fails than automatically request will be serverd by other server (without SSL)?
Please help me regarding how to address this scenario.
Above description might be not detailed but if you want I can describe more.
Thanks in advance.
I am trying to implement third party authentication with openAM, and have a doubt regarding openAm implementation, i.e if my application is distributed under different servers which are geographically separated and controlled under the same DNS name. How can I differentiate the sessions of different server. Say for example if I type www.google.com it can forward to any of the nearest server available, now if I have to authenticate google.com how will my openAm know that the request is for that particular server. If I ask it in other way, so whenever we are changing a policy in openam or invalidating a session it callbacks to all the registered server, now in distributed environment how it can differentiate the server IP's
I assume you have some sort of LB in front of you servers. I would suggest creating a sticky session at the LB, like a cookie saying what server the user is on before starting the authentication. Then when authentication i done, openam redirects back to your LB and the LB directs to the correct server.
I'm working on a project which requires delegation in a double-hop scenario. We have a desktop client, connecting to a WCF service using a net.tcp binding, connecting to a SQL database on another server. Our goal is to use the user's credentials to access the SQL database.
Both the WCF service and SQL database are running under the same domain user, which has delegation enabled for the SQL database. The instructions here have been followed, with no success.
Now, some details recorded in our logs:
The login used on the SQL database appears as the user the WCF service is running under, and uses Kerberos.
The login used on the WCF server appears as the client's user, but uses NTLM.
Using either [OperationBehavior(Impersonation = ImpersonationOption.Allowed)] or using (ServiceSecurityContext.Current.WindowsIdentity.Impersonate()) results in commands being run as the client, on the WCF server. This leads me to believe impersonation is working fine.
So, what could be causing the first hop to fall back to NTLM? We suspect it's a SPN issue, but we've registered the SPNs of both the WCF service and SQL service to the shared domain user. Also, as per the instructions listed above, we've set the SQL service as trusted for delegation on the domain user.
We've used EndpointIdentity.CreateSpnIdentity on the WCF service to set the SPN, and this is the SPN we've registered to the domain user.
Any suggestions? Thanks in advance!
Edit:
We've found something that may have been an issue - We had not used EndpointIdentity.CreateSpnIdentity on the client. After setting this we receive the error
“call to SSPI failed” with an inner exception of “target principle name is incorrect”. But the SPN we've set in the client and the server match, and both match the hostname of the service. If we set both the client and the server SPN to something completely different, or if the client's specified SPN does not match the server's SPN, authentication falls back to NTLM as it did before. We've done research into the error, but cannot find its cause. Any suggestions?
We've also performed packet captures of both cases - falling back to NTLM and when we receive the "call to SSPI failed" error. In both cases, similar packets are sent and received until, on one, NTLM is mentioned. On the other, a "TURN CHANNEL" packet is sent from the client to the server. The packets contain nothing human readable except the IP address of the server until either NTLM is mentioned, and the username and computer names are sent, or the "TURN CHANNEL" packet is sent, which contains what appears to be the SPN, and possibly the hostname. There doesn't appear to be any human readable error codes or error messages. Any suggestions on what to look for in the packets?
We found our error - the client was creating the connection using the IP address of the server. After switching the IP to a fully qualified domain name, the first hop consistently authenticates using Kerberos.
The IP address resolves to the same string we used in both SPNs, but I suppose the client checks if the connection string matches the portion of the SPN following the slash before performing any other checks.
We tested our results using both Network Service and our domain user, and as long as the SPN was registered to the computer or user respectively, there were no issues.
Hopefully this answer will save others some time and hassle!
Additional Note: While this enabled Kerberos authentication for all connections, we later discovered that this was unnecessary in our situation. Part of our connection to the database was not inside the impersonation using block, which was causing the table read to fail. We have since removed all delegation and SPN related code, and the database connection continued to work correctly. Our first hop is using NTLM. We're not exactly sure how the credentials are being used at the SQL server, as our connection appears to be exactly what is described as the double hop scenario, which should require Kerberos and delegation, but it's hard to argue with what's working. I suspect it may have something to do with the note located under delegation in this document:
When a client authenticates to the front-end service using a user name and password that correspond to a Windows account on the back-end service, the front-end service can authenticate to the back-end service by reusing the client’s user name and password. This is a particularly powerful form of identity flow, because passing user name and password to the back-end service enables the back-end service to perform impersonation, but it does not constitute delegation because Kerberos is not used. Active Directory controls on delegation do not apply to user name and password authentication.
If anyone has any other suggestions for the reason it's working, I'd love to hear them. However, I don't feel it's worth opening another question for.
i'm having a problem using Load-Balancing on my server (using IIS 6). I have a Manager Website that works correctly most part of the time, but sometimes when i go to another page inside this manager, instead of redirecting to the correct page, it redirects to the login page of it.
I don't think this is a timeout problem, because if i press F5 it redirects to the correct page. I suppose it's a problem with the Load-Balancing, because I tried to run the Manager in another machine without Load-Balancing (still using IIS 6) and it worked fine.
I'm using ASP.NET 3.5.
Could someone figure out why this is happening?
If session information is stored locally on a web server then when a load balancer sends your request to another server (say server2) in this farm - server2 doesn't have session information about your request and it correctly sends you to the login page. When you hit F5 load balancer sends you to the original server1 which has authentication information and successfully displays the page.
You need to store session information in a central location so that all servers in the farm could see it.
One way is to store sessions in a centralized place, as already pointed by DmitryK, other way is to forward the request of one session to only one server. So that ASP.NET can found sessions for that. You can use Cookie based request forwarding or IP based request forwarding. IP based forwarding may not work in some cases, if the ip's are masked by some NAT(Network Address Translation). Please check what all options are provided by your load balancer.