LDAP Authentication has been enabled.
Test LDAP Connection returns successful.
Test LDAP Users returns with a list of users.
Test LDAP Groups is successful as well.
I sign out of Test#Liferay.com and try logging in as on of the users returned from "Test LDAP Users."
Authentication fails.
Liferay throws authentication fails very quickly as if it did not even check against Active Directory.
Any suggestions? Thanks!
Liferay does not connect to LDAP to do authentication. It imports LDAP entities (user/groups) into it's own db. Only after import you can authenticate with user from LDAP (Liferay's copy of user).
How did you setup LDAP import setting? On startup? Periodically?
UPDATE:
Do you have errors in logs regarding ldap import?
Which version of Liferay do you use?
Do you have export to ldap enabled? (that never worked for me, meaning import failed because of export)
I also suffered with this problem before. I solved it now.
Do you enable the Export of LDAP. How you are doing the ldap configuration if you are using control panel-> Portal Setting then
You can check the search Filter of User portion and set objectClass=inetOrgPerson
Usually the best way to start troubleshooting these things is to get a network trace with something like WireShark and see what calls are being made as well as the corresponding replies.
Related
I've desperately been trying to connect my liferay installation with our MS AD to import the users into the MySQL DB so that all the existing users from the AD are able to log in to the liferay instance.
I configured everything as follows:
https://i.stack.imgur.com/ueGWq.jpg
When I "test the users", I get everything I want except for the "password" which should be displayed encrypted or in asterisk symbols. No matter what I do, the attribute does not show up.
https://i.stack.imgur.com/3OsXe.jpg
Any tips?
Best regards and thanks in advance!
I have an Azure Function app, written in C# and using .NET Core (3.x) running on Linux. I would like this set of functions to be able to connect to an Azure SQL database. I have followed this process:
I ensured that the function app has system-assigned managed identity enabled:
I created a user in my database using CREATE USER ... FROM EXTERNAL PROVIDER and added the user to the appropriate roles (db_datareader and db_datawriter in my case). In my case, I had to create an Azure AD group and add the managed identity to the group, and then create the user for the group (there were two AD identities with the name of the function app, for some reason...).
I set up the connection string in the function app's settings. This is where I think I've gone wrong. I am not clear on how to specify the correct connection string. Connection strings I tried:
Data Source=my-database-server.database.windows.net;Initial Catalog=my-database did not work. I saw errors such as this: Login failed for user ''.
Data Source=my-database-server.database.windows.net;Initial Catalog=my-database;Authentication=Active Directory Integrated (using System.Data.SqlClient) did not work. I saw errors such as this: Keyword not supported: 'authentication'.
Data Source=my-database-server.database.windows.net;Initial Catalog=my-database;Authentication=Active Directory Integrated (using Microsoft.Data.SqlClient) I saw errors such as this: MSAL cannot determine the username (UPN) of the currently logged in user.
What is the magic connection string incantation, or step that I am missing?
Use Microsoft.Data.SqlClient instead of System.Data.SqlClient if getting Keyword not supported: 'authentication'
More details on various values for authentication= and suppported library versions can be found here:
https://learn.microsoft.com/en-us/sql/connect/ado-net/sql/azure-active-directory-authentication?view=sql-server-ver16#setting-azure-active-directory-authentication
I can't claim any credit for this solution, I found it on reddit of all places!
I configured our Cloudera Navigator service to authenticate via LDAP. I'm able to login in Navigator, however I instantly get an error:
You are not authorized to view this page
When I log in with full administrator and try to search for LDAP groups to add, I get nothing returned, so I think there is something wrong with my configuration. Where should I be able to see how does the LDAP query look like?
I use identical settings for LDAP as I used when configuring Cloudera Manager, where everything works fine. The LDAP group I'm looking for has a "Navigator" admin role assigned in CM.
I would use this tool to monitor which queries are performed on the AD :
https://learn.microsoft.com/fr-fr/sysinternals/downloads/adinsight
We have one domain with trust (not-transitive) to two other domains. The base domain user can login without any problems, but the users from other domains cannot.
We get exception from ADFS like this:
The Federation Service encountered an error during an attempt to
connect to a LDAP server at {trusted domain}.
Additional Data Domain Name: {trusted domain} LDAP server hostname:
{trusted domain dc} Error from LDAP server: Exception Details: A
local error occurred.
User Action Check the network connectivity to the LDAP server. Also,
check whether the LDAP server is configured properly.
After reserching we found out, it's the one-way trust problem. The problem is, we don't have any posibility to change the trust configuration or to set up other ADFS on trusted domains.
Is there some possibility to get it to work? Maybe some work around solution?
Is it possible to change the FormSignin page, search the user manualy with DirectoryServices and manualy create the token?
Thanks All!
Not sure if there's a way to do it if you keep your ADFS service account in the trusting domain (in a one-way trust scenario). You would need to allow that account to be able to query LDAP in the trusted domain, which would usually mean a two-way trust.
Absent that, you may try to setup use an ADFS service account from the trusted domain. Of course, this would only work for one of your domains (unless the two other domains have trusts between themselves).
I am trying to authenticate my apache against kerberos.
I have two websites running on the same server, and I use VirtualHosts to achieve that and set DNS to have two names for this server to have a separate one for each website.
I added recently a new ldap/Kerberos server and trying to connect one of my websites to it, but I failed to get the correct credentials to get it works.
After adding some debugs, I found that apache looks for HTTP/fist-server-name instead of HTTP/second-server-name and for that reason couldn't find the correct principal in Kerberos database and keytab.
How to force apache to do its check against the second server name to validate the call from my second website? It looks adding ServerName attribute in apache configuration is not enough to do that!
I am able to do that by changing the server name orders in hosts file, but this can't help if I want to authenticate from the both server names!
Thanks.
I'm assuming that you're using mod_auth_kerb. You need to add:
KrbServiceName Any
to your Apache configuration. This will tell mod_auth_kerb to accept authentications to any principal for which there is a key stored in the keytab it uses, rather than making assumptions about what principal will be used and only accepting authentications to that principal.
You need to identify which Kerberos SPN you want to use for each website. You can check what SPNs are listed in your keytab by running: klist -k <Keytab> -- make sure that you're checking the keytab file that Apache uses.
In the VirtualHost declaration you need to change the KrbServiceName value to match the one that you identified from the keytab. Restart Apache and it should start using that when communicating with Kerberos.
An example would look something like:
KrbServiceName HTTP/yourservice.domain#REALM.COM
Make sure that AD has a service account and SPN that matches and that it can resolve via DNS back to the Apache server.
I found this recently in the MIT Kerberos documentation on Principal names and DNS:
Applications can choose to use a default hostname component in their service principal name when accepting authentication, which avoids some sorts of hostname mismatches. Because not all relevant applications do this yet, using the krb5.conf setting:
[libdefaults]
ignore_acceptor_hostname = true
will allow the Kerberos library to override the application’s choice of service principal hostname and will allow a server program to accept incoming authentications using any key in its keytab that matches the service name and realm name (if given). This setting defaults to “false” and is available in releases krb5-1.10 and later.