I have to import users from two different base dn. My Users lie in following structures
ou=users,ou=dev,dc=abc,dc=net
ou=users,ou=qa, dc=abc,dc=net
Rest of the properties like base.provider.url and security credentials are same for both. What is the correct way to import and authenticate users from both the above DNs in Liferay.
Right now i have provided properties like this in portal-ext.properties
ldap.base.provider.url.0=ldap://localhost:10389
ldap.base.dn.0=ou=users,ou=dev,dc=abc,dc=net
ldap.security.principal.0=username
ldap.security.credentials.0=password
ldap.base.provider.url.1=ldap://localhost:10389
ldap.base.dn.1=ou=users,ou=qa,dc=abc,dc=net
ldap.security.principal.1=username
ldap.security.credentials.1=password
Is it the correct way of importing and authenticating in my scenario. It seems to work intermittently. That is sometimes user is authenticated against ldap and sometimes it is not. I have not changed any settings from Control Panel.
Please have a look into following link it may help you..
Instead of using portal-ext.properties file use Admin Control panel to configure LDAP.
http://www.liferaysavvy.com/2013/10/liferay-ldap-integration_8.html
Related
I am trying to configure Grafana for my organization. I was able to configure LDAP and MySQL database pretty easily but when I try to invite a new user to an org in Grafana, it always asks the user to join Grafana.
This would be an OK behavior if at that point Grafana would authenticate against LDAP. Instead, it creates a new user in its own database. This would lead to conflict with LDAP in case the user's AD passwords changes.
This works perfectly when a user had previously logged in to Grafana. An invite sent after would directly take the user to login page.
Is it possible to do the same in case the user is not already registered in Grafana? I really want to avoid saving user credentials in Grafana database.
Any help would be appreciated. Thanks.
I am not a Grafana expert, but looking through the source code on GitHub it certainly seems that new user registration will not go through LDAP. This is obvious in the LDAP related configuration file where you see the read-only credentials needed to look up users in the LDAP directory. A read-only administrator in LDAP will not be able to create new users as this would be necessary during a registration step. The code also indicates that registration creates temporary users in the internal store.
I've just installed Testlink and am trying to get familiar with it.
I've even managed to configure authentication using LDAP (Microsoft AD).
But strangely, as soon as I set LDAP as default authentication method, my local test users cannot log on anymore.
If I change back to DB authentication as default auth method, my LDAP users cannot log in anymore.
I've the following set in the configuration file:
$tlCfg->authentication['domain'] = array('DB','LDAP');
$tlCfg->authentication['method'] = 'LDAP';
It seems as if both authentication modes are enabled and LDAP is used as the default.
When editing the user settings of a user, I have a dropdown box named "Authentication method"
It has three entries. One is "Default", the other is "0" and the third is "1".
This led me to the assumption, that I can select the type of authentication used for this account.
But strangely, regardless of which option I choose, the behavior is identical to what I mentioned above.
Is anyone experienced in Testlink?
Does anyone use two authentication modes in parallel with Testlink?
Did anyone see the same issue before? What did you do to solve this issue?
Thanks for your help in advance!
Best regards,
Tom
You can use testlink DB authentication as well as LDAP authentication. You have to set this option when you create user
Dropdown box named "Authentication method" has three entries. One is "Default (LDAP)", the other is "DB" and the third is "LDAP". If you see different options then something is messed up with your TestLink installation. I'm using v1.9.14 on MySQL.
I need to call LDAP to see if the user exists.
The registration of the account will be enabled only for screenName that are present on LDAP.
I have configured LDAP correctly on Liferay but I do not have to enable importing from LDAP.
Which class and method should I use just to check if the screenName exists on LDAP?
Thank you for your help
you can do this replacing default Screen Name Validator, overwriting the next property at portal-ext.properties
users.screen.name.validator=com.liferay.portal.security.auth.DefaultScreenNameValidator
Put your [package].[class] here. Please, check the following link, can guide you:
https://github.com/liferay/liferay-portal/blob/master/portal-service/src/com/liferay/portal/security/auth/DefaultScreenNameValidator.java
At the end, you only need to implement the ScreenNameValidator interface
Cheers!
Using the Jenkins OpenID plugin I'm able to configure Jenkins to use my Google Apps OpenID as a provider. Anonymous users are still able to access that application (they have read access only), but I want to have it so that users are forced to login using the Google App domain or they are denied access.
I'm currently using the Jenkins Authorization setting of "Logged in users can do anything", I've tried using the "Matrix based authentication" and denying anonymous users, assuming logged in users would still have permissions, is there a special group value I can use for "logged in users" in matrix based authentication?
It seems like "Matrix-based security" will only work for specific users when using Google Apps OpenID (I don't believe Google apps for domains has support for OpenIDTeam extension
Yes there is a special group you can use to do this but finding the information about how to do it isn't obvious.
If you hover over the 'Overall - Read' column on the Matrix-based security table you'll get the solution.
It states
The read permission is necessary for viewing almost all pages of Jenkins. This permission is useful when you don't want unauthenticated users to see Jenkins pages - revoke this permission from the anonymous user, then add "authenticated" pseudo-user and grant the read access.
I use the following technique in combination with the OpenID plugin which allows me to specify a Google Apps for Business domain to secure Jenkins with
Warning: Make sure you've got a backup of your installation before you start because if you get something wrong you may lock yourself out of your Jenkins. Unpicking the plugins and settings would take longer than just restoring from a backup.
Ensure your choice of OpenID provider is still working ok with your current 'Logged in users can do anything' setting
Select the 'Matrix based-security' mode for Authorization
Add a new 'authenticated' group (lower case 'a') to the Matrix-based security table.
Use the 'check all' icon at the right hand end of the new 'authenticated' row to tick all the permission boxes.
Use the 'check all' icon at the right hand end of the 'Anonymous' row to untick all the permission boxes.
Save the settings
Reload Jenkins
Now each time a user wants to see Jenkins they have to be already signed into their Google Account and no-one can get to see any Job names or views without login.
Hope this helps.
We have our own web server hosting our website that is open to the public outside of our network.
I have a request to make our "Internal Postings" link on our Careers page to authenticate the user against our network's Active Directory list.
I currently have it setup so the link hits a page inside the directory structure of the website, and this page's folder is set to "Integrated Windows Authentication". Anonymous access is turned off for this page. If the user is authenticated (ie: logged into our network or supplies proper credentials) it passes them on to an external careers website which hosts our job postings. If they fail to authenticate, it displays a custom 401 error page.
This works fine, but there is a problem with it. Using IE, people cannot just enter their username. They (of course) are required to enter the domain name as well. Unfortunately the default 'domain' is set to the URL of our website (www.xyz.com/username). I would like it to automatically choose the name of our internal domain (aaa/username) but am unsure of how to do this.
Another option would be to use LDAP and a little ASP scripting to authenticate the user. I have this code already, but am unsure of the security consequences of doing so. Basically, the page will be setup for anonymous authentication, and if the user isn't logged into our network, they will be prompted for a username/password using standard textboxes. This is then passed to an ASP script that does an LDAP lookup against our Active Directory. Is there any security issues with this method?
Which method would you choose to do?
Thanks.
EDIT: It seems I cannot authenticate to ActiveD via LDAP using a username/password combo. So forget about that option.
My question now is, how can I change the default 'domain' that IWA uses? Is that at all possible? IE seems to default to 'www.xyz.com\username' (my website) rather than 'aaa\username' (my domain name). Of course, www.xyz.com\username fails because that is not where our ActiveD resides... Is this possible? I want to make it as simple as possible for our employees.
You cannot authenticate an user with a script that looks up the user in LDAP. You need to know that the user is who it claims it is, and the only way to do that is to let NTLM/Kerberos authenticate the user (ie. establish proof that the user knows a secret stored in the AD, the password).
The URL of the web site to the set of sites considered be in the local intranet zone for IE browsers running on the internal network. By default sites consider to local intranet will be sent the current logged on users credentials when challanged with NTLM/Kerberos. Hence your internal users shouldn't even see a network logon box.
I hate to dredge up an old thread, but the answers are a bit misleading, if I understand the question. The thread Remus refers to is about authenticating via LDAP with a username only. As he points out, that isn't possible. But it looks like what Kolten has in mind is authenticating via LDAP with a username and password both. That's a standard practice called binding.