I'm writing code to connect to my Active Directory server using LDAP. I can connect using
LDAP://celtestdomdc1.celtestdom.local
but I can't connect using
LDAP://celtestdomdc1.celtestdom.local/CN=Users;DC=celtestdom
Am I using the wrong syntax or something?
Your LDAP string is wrong - use:
LDAP://celtestdomdc1.celtestdom.local/CN=Users,DC=celtestdom,DC=local
or even this (server-less binding - goes to the default DC)
LDAP://CN=Users,DC=celtestdom,DC=local
First, the parts need to be separated by comma (,) not semicolon - and second, you need to use the DC=.... for all DNS-parts of your domain.
<shameless plug>
Also you might want to look at my ADSI browser called Beavertail which is written in C# and 100% free and open-source. It will show you what your domain tree looks like and what the valid LDAP paths are.
</shameless plug>
Related
I'm hoping someone can shed some light on this issue. I'm attempting to programmatically add datasources to the Lucee Server context (ie. not on a per-application basis, but rather datasources that are made available to all web contexts on the server). The following call to the tag to create the datasource or later update the same datasource results in the connectionString never being saved correctly.
NOTE: "updateDatasource" will create a datasource if it doesn't already exist.
Host Environment: Windows Server 2019 running Lucee 5.3.8.206 on OpenJDK17.
Database Environment: Windows Server 2019 running SQL Server 2019.
<cfadmin
action="updateDatasource"
type="server"
password="F4K31234"
bundlename="org.lucee.mssql"
bundleversion="8.4.1.jre8"
classname="com.microsoft.sqlserver.jdbc.SQLServerDriver"
dsn="my_new_datasource"
name="my_new_datasource"
newName="my_new_datasource"
connectionString="jdbc:sqlserver://SQLSERVERNAME\MSSQLSERVER2019;DATABASENAME=my_database;sendStringParametersAsUnicode=true;SelectMethod=direct"
dbusername="Temp1234"
dbpassword="F4K31234"
connectionLimit="100"
alwaysSetTimeout="true"
validate="false"
allowed_select="true"
allowed_insert="true"
allowed_update="true"
allowed_delete="true"
allowed_create="true"
allowed_revoke="true"
allowed_alter="true"
allowed_grant="true"
clob="true"
lineTimeout="60">
Every time this operation is attempted, the Connection String is stored as "my_database". In other words, it appears to ignore the string provided in the connectionString attribute and instead stores the database name for the datasource connection string.
These settings are exactly what I use when manually setting up a datasource in the Lucee Server administrative area (minus the obvious fake username, passwords, server names, and database names).
Before I go about filing a bug, I wanted to be sure I'm not missing something here. I appreciate any insight!
Need some help, because I can't find any solution for my problems with DBD::Oracle.
So at first, this is the current situation:
We are running Apache2 with mod_perl 2.0.4 at our company
Apache web server was set up with a startup script which is setting some environment variables (LD_LIBRARY_PATH, ORACLE_HOME, NLS_LANG)
In httpd.conf there are also environment variables for LD_LIBRARY_PATH and ORACLE_HOME (via SetEnv)
We are generally using the perl module DBI with driver DBD::Oracle to connect to our main database
Before we create a new instance of DBI we are setting some perl env variables, too (%ENV). We are setting ORACLE_HOME and NLS_LANG.
So far, this works fine. But now we are extending our system and need to connect to a remote database. Again, we are using DBI and DBD::Oracle. But for now there are some new conditions:
New connection must run in parallel to the existing one
TNSNAMES.ORA for the new connection is placed at a different location (not at $ORACLE_HOME.'/network/admin')
New database contents are provided by stored procedures, which we are fetching with DBD::Oracle and cursors (like explained here: https://metacpan.org/pod/DBD::Oracle#Binding-Cursors)
The stored procedures are returning object types and collection types, containing attributes of oracle type DATE
To get these dates in a readable format, we set a new env variable $ENV{NLS_DATE_FORMAT}
To ensure the date format we additionally alter the session by alter session set nls_date_format ...
Okay, this works fine, too. But only if we make a new connection on the console. New TNS location is found by the script, connection could be established and fetching data from the procedures by cursor is also working. Alle DATE types are formatted as specified.
Now, if we try to make this connection at apache environment, it fails. At first the datasource name could not resolved by DBI/DBD::Oracle. I think this is because of our new TNSNAMES.ORA file or rather the location is not found by DBI/DBD::Oracle in Apache context (published by $ENV{TNS_ADMIN}). But I don't know why???
The second problem is (if I create a dirty workaround for our first one) that the date format, published by $ENV{NLS_DATE_FORMAT} is only working on first level of our cursor select.
BEGIN OPEN :cursor FOR SELECT * FROM TABLE(stored_procedure) END;
The example above returns collection types of object which are containing date attributes. In Apache context the format published by NLS_DATE_FORMAT is not recognized. If I use a simple form of the example like this
BEGIN OPEN :cursor FOR SELECT SYSDATE FROM TABLE(stored_procedure) END;
the result (a single date field) is formatted well. So I think subordinated structures were not formatted because $ENV{NLS_DATE_FORMAT} works only in console context and not in Apache context, too.
So there must be a problem with the perl environment variables (%ENV) running under Apache and mod_perl. Maybe a problem of mod_perl?
I am at my wit's end. Maybe anyone in the whole wide world has a solution ... and excuse my english :-) If you need some further explanations, I will try to define it more precisely.
If your problem is that changes to %ENV made while processing a request don't seem to be honoured, this is because mod_perl assumes you might be running multiple threads and doesn't actually change the process environment when you change %ENV, so external libraries (like the oracle client) or child processes don't see the change.
You can work around it by first using the prefork MPM, so there aren't any threading issues, and then making changes to the environment using Env::C instead of the %ENV hash.
I'm getting cannot verify the quality of the non-cleartext passwords error while trying to add an entry into my organizationalUnit. I use MD5 hashing method while storing password. (with userPassword attribute)
A blog post says the solution is adding ads-pwdcheckquality attribute with value of 0; but it didn't work for me. And also while trying to add this attribute; it gives a warning like this:
You don't need to add a new attribute, you need to edit the server configuration and restart:
1-Open config.ldif in the server folder, search for the string:
ads-pwdcheckquality: 2
and change it to:
ads-pwdcheckquality: 0
2-After that, restart the server and try again. The solution worked for me.
I have a program that will run a query, and return results in report viewer. The issue is we have 10 locations, all with their own local database. What I'd like to do is have each location use the program and utilize the App.config file to specify which database to connect to depending on which location you are. This will prevent me from having to create 10 individual programs with separate database connections. I was thinking I could have 3 values in the app.config file "Database" "login" "password" Generally speaking the databases are on the .30 address... so it would be nice to be able to have them set the config file to the database server IP...
For example:
Location: 1
DatabaseIP: 10.0.1.30
Login: sa
Password: databasepassword
Is it possible to set something like this up using the app.config file?
You should take a look on the resource files.
Originally, they are intended for localization, but they should work for you also.
Go to your project Properties, and set up an Application Setting --> Type (Connection String) from the drop down. This will result in a xlm config file in your output directory in which you can modify the connection string post-compile.
I ended up using a simple XML File to do this. I used this site to accomplish it. I first wrote the XML using the form load, then switched it to the read.
I'm creating an in-house application and have always hardcoded the database connection string. However, this time I want to do something different and give the users the ability to enter the information from the application.
I figured out that I can store the variables in the Application Settings and call them from code, but I can't figure out how to call them within the connection string.
Here's the code:
Dim dbConn As New MySqlConnection
dbConn.ConnectionString = "Server=172.43.96.271;Port=3306;Uid=someone;
Password=theirpassword;Database=thedb"
Hope I explained myself well?
You can simply concatenate the string together, or better yet, use the String.Format method:
dbConn.ConnectionString = String.Format("Server={0};Port={1};Uid={2};Password={3};Database={4}", My.Settings.Server, My.Settings.Port, My.Settings.Uid, My.Settings.Database)
If you were using MS SQL, I'd recommend using the SqlConnectionStringBuilder class to do it, but since you're using MySql, it doesn't really apply. You may be able to use it anyway, though.
You would have to use User Settings for this.
And, if you want the users to input the separate parts of the connection string (Server, Post, Username, Password and DB), you would have to create a settings entry for each of those, and then construct the connection string from those values.
Here's a good article for this: User Settings Applied