I have a requirement to configure LDAP properties to add a new ldap connection in a Nexus container(I'm using a containerised version of Nexus,version 3.28.1) from the command line.
The properties include:
ldap host.
port.
protocol,
search base dn,
authentication method,
Username or dn,
User relative dn,
object class,
user id attribute,
real name attribute,
email attribute.
I have tried adding the properties in nexus-data/etc/nexus.properties file with nexus.ldap.env as the prefix ,but it was not reflecting in the UI.I have also tried accessing the
orientdb from the container by running nexus-orient-console.jar and connecting to the config class and adding an entry to the ldap table.That too,was not getting reflected in the UI.
Appreciate any help.
Related
SonarQube 8.6+ enforces user authentication by default.
How do I allow anonymous access since the first startup?
I am running SonarQube on a local Docker Container and I would like to automate this step. That is, I am looking for a solution not involving:
Log on to SonarQube with the default credentials (login: admin, password: admin).
Change the default password.
Manually disable the Force user authentication property from Administration > Configuration > General Settings > Security.
You could enable the anonymous access by adding the following property to the $SONARQUBE-HOME/conf/sonar.properties file:
sonar.forceAuthentication=false
How to modify the file in Docker you can find here: https://stackoverflow.com/a/27714071/4944847
I am working for an IBM Business Partner and I am trying to complete a first PoC ICP installation. The basic installation has worked. I did not configure LDAP during the deployment but I am trying to add an LDAP connection in the console now, afterwards.
Unfortunately, I always fail. And there seem to be a number for limitations and/or bugs in the LDAP connection of ICP to the point of making it unuseable.
First, I would like to connect to an IBM Domino Directory as my LDAP server. Anyone who has worked with a Domino directory before knows that many Domino deployments have an O=Org suffix where Org is a company name containing spaces. For example, in our case it is "O=ARS GmbH". I would normally need to use this as the base DN (search base). However, ICP does not allow spaces in this field ... that need to be fixed! Any other LDAP client product I tried to connect to our Domino directory over many years was able to deal with spaces in the base DN.
Next, in a Domino directory usually the groups do have a different suffix (e.g. search base) than users. But ICP only offers ONE base DN field and not separate base DN fields for users and groups. Any other LDAP client ... DOES offer this. This needs to be fixed in ICP as well.
Next, the bind DN field does not allow some commonly used special characters which are often found in account names, such as the - character. This needs to be fixed as well (as it happens, the special user ID we have in our Domino directory which we use for LDAP binding is named dir-client ...).
Well, after hitting all those blocking problems, I finally tried to connect to our Microsoft Active Directory. This time I could successfully complete the LDAP connection. After doing so, I turned to "Users" and discovered I need to "Import group". However, no matter what I try to enter as (correct) values into the CN and OU fields, I only end up with an "internal server error".
Further more, after I could save the LDAP connection to Active Directory, I could no longer log in to the console with the builtin admin account! But since I could not import any users/groups, I could not assign that role to an LDAP account ... luckily, I had a VM snapshot of the master server and could thus revert to the state before.
This is really frustrating ...
I ran into identical issue when hooking up to an openldap server running in a docker container. It took me awhile to figure out the ICP pod and container where the log file is to get more information than "Internal Server Error".
Here is how to find the relevant ICP pod/container log:
Look for the "auth-idp" pods in the kube-system namespace. I use:
kubectl get pods --namespace=kube-system | grep auth-idp
If you are running an HA cluster, you will have a pod on each master node.
In my case I have 3 master nodes. If you are running only a single master, then you will have only one auth-idp pod.
Again, in an HA scenario, you need to figure out which is your current master node. (The easiest, crude way to do that is ssh to your master VIP and see which node you land on.)
Now figure out which pod is running on the current master node. On each pod I use:
kubectl describe pod auth-idp-vq5bl --namespace=kube-system | grep IP
or
kubectl get pod auth-idp-vq5bl --namespace=kube-system -o wide
The one on the IP that is the current master node is where the log of interest will be.
The container in the pod that has the log of interest is: platform-identity-mgmt
To actually see the log file use:
kubectl logs auth-idp-vq5bl --namespace=kube-system --container=platform-identity-mgmt
At that point you will be able to scroll through the log and see a more detailed error message.
In the case of my error the log indicated my search filter for the group was not working properly. I decided to mess with the user ID map and user filter so I used a user ID map of *:cn and a user filter of: (&(cn=%v)(objectclass=inetOrgPerson)) Once I changed those in the ICP LDAP configuration, the user import succeeded. However, later I realized the logins were not working because the login is based on a search on userid or uid. So I changed the user ID map back to *:uid and the user filter back to (&(uid=%v)(objectClass=inetOrgPerson)). That corrected the login issue. I added some users to my LDAP group and reimported the group and the import worked as well. At this point, I'm not sure what was going on with the original import not working until I messed with the user ID map and user filter. Go figure.
In my OpenLDAP directory instance my groups are all under ou=groups and each group member is listed as, e.g., cn=Peter Van Sickel,dc=ibm,dc=com. I had to edit the group member to get it using the full DN of an actual user.
My users are all directly under the root DN: dc=ibm,dc=com.
As to specific issues with other LDAPs, it is my experience that each has its own set of idiosyncrasies to get things working as desired.
I am using Liferay 6.2 and I am trying to do LDAP Authentication. The LDAP Server is provided by another organization and I do not have access to any configuration, I just have credentials for a system account to look up the directory. When I try to log in Liferay with user credentials from the LDAP Server the authentication fails with the following error code:
13:54:05,738 ERROR [http-bio-8080-exec-3][LDAPAuth:341] Problem accessing LDAP server
javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D: NameErr:
DSID-0315270B, problem 2001 (NO_OBJECT), data 0, best match of:
'O=uni,C=de' remaining name 'ou=people,o=uni,c=de'
The same error that occurs when trying to log in with a user that does not exist in the LDAP directory. Nevertheless, the mapping still works. After trying to log in with valid user credentials there is an entry in the liferay database with the corresponding user data. Accessing Liferay is not possible though.
These are my settings in portal-ext.properties (Test LDAP connections returns success, connection settings are pseudonymised):
ldap.base.provider.url=ldaps://ldap.ldap-server
ldap.base.dn=ou=people,o=uni,c=de
ldap.security.principal=uid=prox,ou=prox,o=uni,c=de
ldap.security.credentials=secret
#auth.pipeline.enable.liferay.check=false
ldap.auth.enabled=true
ldap.auth.required=true
ldap.auth.method=bind
ldap.import.enabled=false
ldap.import.on.startup=false
ldap.import.interval=10
ldap.export.enabled=false
ldap.export.group.enabled=false
ldap.auth.search.filter=(uid=#screen_name#)
ldap.import.user.search.filter=(objectClass=inetOrgPerson)
ldap.attrs.transformer.impl=com.liferay.portal.security.ldap.DefaultAttributesTransformer
ldap.user.mappings=screenName=cn\npassword=userPassword\nfirstName=givenNam\nlastName=sn\njobTitle=title\ngroup=groupMembership
users.email.address.required=false
users.email.address.auto.suffix=#no-emailaddress.com
users.email.address.generator=com.liferay.portal.security.auth.DefaultEmailAddressGenerator
users.email.address.validator=com.liferay.portal.security.auth.DefaultEmailAddressValidator
ldap.password.policy.enabled=false
ldap.import.user.password.enabled=true
ldap.import.user.password.autogenerated=false
ldap.import.user.password.default=test
Check the FQDN on the LDAP side, including the prefixes (cn, ou, etc.), and ensure that it matches the directory configuration within Liferay.
You can try configuring it from the control panel it will be easier for you as it allows to check whether the connection is made or not. You can check the users are fetched or not and it doesnt even need a server restart.
It works now. There were two issues:
I changed ldap.base.dn=ou=people,o=uni,c=de to ldap.base.dn=o=uni,c=de and
ldap.import.user.search.filter=(objectClass=inetOrgPerson) to ldap.import.user.search.filter=(objectClass=*)
I have WebLogic 11G (10.3.6) on Linux Server and SQL Server 2012 on Windows 2012. I would like to create the connection pool to SQL Server from WebLogic using Windows Active Directory Kerberos authentication.
I am looking for steps to accomplish the above. I found information in bits and pieces but looking for clear steps. Any help is greatly appreciated.
I have access to WebLogic 10.3.3. So all version numbers are according to that. But the principals are the same.
Login through the console
Lock and Edit. If this isn't a production mode server, you won't need to do this.
Go to Services > JDBC > Data Sources and click "New".
Give it a name and JNDI name. I probably don't need to mention that the JNDI name is the important one. Also, choose the "Database Type" as "MS SQL Server".
Next you'll have to choose the driver. I didn't observe anything about distribute transactions in your question. Thus, I'm assuming you won't need an "XA" driver.
Again, I didn't see anything about Global Transactions in your quesiotn. So in the next step, disable it.
Next is the information about your Database; its name, Host's IP, and Port. If you have a named instance, add the name after the IP like this: \\instance_name. Since you want to use Kerberos, don't enter the Username and Password.
In the next step, you need to tell your datasource to use kerberos. Add ";AuthenticationMethod=kerberos" to end of the URL field. Connection properties are separated with a ";". For example, jdbc:sqlserver://192.168.10.56:17888;AuthenticationMethod=kerberos
Next, specify which Servers in your Domain will have access to this DataSource. Basically, specifying the DataSource's target servers.
Side notes and other important settings:
When you specify the "AuthenticationMethod" connection property with the value of "kerberos", any username or password will be ignored.
Your database server must be administered by the same Domain Controller that administers the Weblogic server.
Under $WL_HOME/server/lib find krb5.conf (Kerberos configuration file containing values for the Kerberos realm and the KDC name for that realm) and open it in a text editor. Specify the system properties java.security.krb5.realm and java.security.krb5.kdc. In Windows Active Directory, the Kerberos realm name is the Windows domain name and the KDC name is the Windows domain controller name.
The application and driver code bases must be granted security permissions in the security policy file of the Java 2 Platform. Something like this:
grant codeBase "file:/WL_HOME/server/lib/-" {
permission javax.security.auth.AuthPermission
"createLoginContext.DDTEK-JDBC";
permission javax.security.auth.AuthPermission "doAs"
permission javax.security.auth.kerberos.ServicePermission
"krbtgt/your_realm#your_realm", "initiate";
permission javax.security.auth.kerberos.ServicePermission
"MSSQLSvc/db_hostname:SQLServer_port#your_realm", "initiate";
};
where:
WL_HOME is the directory in which you installed WebLogic Server.
your_realm is the Kerberos realm (or Windows Domain) to which the database host machine belongs.
db_hostname is the host name of the machine running the database.
SQLServer_port is the TCP/IP port on which the Microsoft SQL Server instance is listening.
I must say though I don't think you searched hard enough. Because almost everything I wrote here came from the online documentation:
http://docs.oracle.com/cd/E12839_01/web.1111/e13753/mssqlserver.htm
I'm trying to configure LDAP authentication for teamcity but can't get it to work. I already configured some other services on this server to authenticate using LDAP and had no problems (so it's not fault of the DC).
Following describes my config file:
java.naming.provider.url=ldap://192.168.0.123:389/DC=server,DC=example,DC=com
java.naming.security.principal=ldap-user
java.naming.security.credentials=jE&4i.%$lpDr3#?
java.naming.security.authentication=simple
teamcity.users.login.filter=(&(sAMAccountName=$capturedLogin$)(memberOf=CN=Group1,CN=Users,DC=server,DC=example,DC=com))
teamcity.users.username=sAMAccountName
teamcity.auth.loginFilter=[^/\\\\#]+
teamcity.options.users.synchronize=false
teamcity.options.groups.synchronize=false
When I set authentication to 'none' it works (but I can't restrict access to a specific group). I also tried using the full user name (incl. domain; i.e. DOMAIN\ldap-user) and also tried to use full DN instead, but it didn't change anything.
In log i see that the ldap server returns error code 49, which means that the binding failed. Like mentioned before I already configured other services on this server to authenticate with the same ldap server and the same binding user and had no problems.
Does anybody know how to solve this issue?
Thanks in advance!
This is my configuration and It working fine. The synchronization is allowed so information like email and name there are no available but enable the login with NT Id and Credentials
java.naming.provider.url=ldap://amer.xxxx.com:389/DC=amer,DC=xxxx,DC=com
java.naming.security.principal=CN=SRVAMR-xxx,OU=CMAPPS,OU=Service,OU=Accounts,DC=amer,DC=xxxx,DC=com
java.naming.security.credentials=Pf867955
teamcity.users.login.filter=(&(sAMAccountName=$capturedLogin$)(memberOf=CN=AMR-GENOME-L,OU=GMA,OU=Security,OU=Groups,DC=amer,DC=xxxx,DC=com))teamcity.users.username=sAMAccountName
I Hope help you