Tuesday, November 15, 2011

Running windows 2008 r2 adprep on a server in a different language

When you have a older active directory system, for example based on a Windows 2003 or Windows 2008 server, you have to upgrade the ads schema by running adprep.exe

The adprep.exe tool is found on the windwos 2008r2 DVD in the support\adprep directory.
You can copy over the whole content of the directory (including subdirectories) to your ads master  server.

If the "old" server is running a 32-bit windows, then you can start adprep32.exe instead of adprep.exe.

Now adprep.exe should tell you something about "At least windows 2000 sp4 required"
If you don't get any messages from adprep, then the languages of the windows 2008r2 dvd and your old ads server do not match.

It might be tempting to just type "c" for continue, it will then do some of the work, but unfortunally not everything you need.
adprep does write a logfile, which can be found in C:\windows\debug\adprep (or C:\windows\system32\debug\adprep for a 32-bit system)
You will see error like

There is a syntax error in the input file
Failed on line 169.  The last token starts with 's'.
An error has occurred in the program

The reason for this is, that there are some strings missing for the adprep utility.
To get it working correctly, you have to rename the language subdirectory to match the servers language. (Chaning it in the control panel is not enough)
For example if your new server is running german, then the subdirectory is called de-de.
If the old server for example is installed in english, you have to rename the de-de directory to en-us.

Now you can again run adprep, you will receive the prompts in the original language from the dvd, but everything will process as expected.

Wednesday, November 2, 2011

Using FTPS with the commons jakarta net library

Using FTPS via the jakarta commons library is not that complicated.

But it has a few things to know:

The correct sequence is this:

FTPClient.connect("YourServer"); 
FTPClient.execPBSZ(0); 
FTPClient.execPROT("P"); 
FTPClient.login("YourUserName","YourPassword"); 

If you skip the execPBSZ or execPROT calls, then your ftps server will probably deny access to you.

If you receive strange errors like:

java.io.IOException: DerValue.getOctetString, not an Octet String 10 

or

Caused by: java.security.cert.CertificateParsingException: java.io.IOException:
DerValue.getOctetString, not an Octet String: 10
        at sun.security.x509.X509CertInfo.(Unknown Source)
        at sun.security.x509.X509CertImpl.parse(Unknown Source)
        at sun.security.x509.X509CertImpl.(Unknown Source)
        at sun.security.provider.X509Factory.engineGenerateCertificate(Unknown S
ource)
        at java.security.cert.CertificateFactory.generateCertificate(Unknown Sou
rce)
        ... 16 more
Caused by: java.io.IOException: DerValue.getOctetString, not an Octet String: 10

        at sun.security.util.DerValue.getOctetString(Unknown Source)
        at sun.security.x509.Extension.(Unknown Source)
        at sun.security.x509.CertificateExtensions.init(Unknown Source)
        at sun.security.x509.CertificateExtensions.(Unknown Source)
        at sun.security.x509.X509CertInfo.parse(Unknown Source)

Then you (or your pfts server) are probably behind a checkpoint firewall.
There is nothing you can do, just talk with the firewall admin and tell him to fix the "FTP Bounce" attack.
He will see this in the logs:

Attack Information: The packet was modified due to a potential Bounce Attack (Telnet Options)

Here is the option to disable this on a checkpoint firewall: