Related to my last post, I made a video covering the IDI assemblyline I wrote to convert ISIM audit XML data to HTML. Here's the video:
And here's the link to the Github repo with the project containing the assemblyline: https://github.com/franktate/IBM-Directory-Integrator
I made a video on using XSLT to convert ISIM's XML reconciliation audit data into more readable XML. Specifically, it takes XML that looks like this:
And turn it into HTML that renders like this:
The video is here: https://youtu.be/7yEkGZGN1Lg and the files used are available in my github repo here: https://github.com/franktate/ISIM-Audit-XML-XSLT
The idisrv.sth file that's included in IBM Directory Integrator isn't a normal stash file. A normal stash file can be decrypted with a simple Perl script (see my previous post). However, this one is different. Happily, IBM does include a method to read this file, though it's hidden in a Jar file and requires some Java know-how.
If you look at the usage from the IDI encryption utility (cryptoutils.sh), you'll see this:
Unfortunately, none of those "-mode" options will let you decrypt values in any of the *.properties files (e.g. global.properties, solution.propterties, etc.) So how do you do it?
To get the answer, you need to find the online documentation here to find that there are two additional options that aren't listed above. They are:
Once you know that, you're over the largest obstacle. But now you have several additional flags with values to provide, and the documentation doesn't give you an example of doing exactly this. So here's the example:
In the above case, I wanted to decrypt the encrypted values in my solution.properties file. My solution directory is /opt/IBM/TDI/ftsoldir. Notice also that you MUST provide the certificate alias that points to the server certificate in the solution directory. By DEFAULT (meaning: all of this can be changed), the alias of that certificate is "server", it is stored in the $SOLDIR/testserver.jks keystore, and the password of the keystore is "server". The name of the keystore and the alias are specified in these two properties in solution.properties:
If, however, you forget the password, that's not a good thing. Normally you can decrypt an IBM stash file with a perl script like this:
#!/usr/bin/perl
use strict;
die "Usage: $0 <stash file>n" if $#ARGV != 0;
my $file=$ARGV[0];
open(F,$file) || die "Can't open $file: $!";
my $stash;
read F,$stash,1024;
my @unstash=map { $_^0xf5 } unpack("C*",$stash);
foreach my $c (@unstash) {
last if $c eq 0;
printf "%c",$c;
}
printf " ";
However, that doesn't work on the IDI stash file (idisrv.sth) because this isn't a GSKit stash file. From the docs:
The stash file contains the Server keystore password values encrypted with AES128 with a fixed key.
Check back later to find out later how to read this stash file - I think I've figured out how to decrypt it.
I did figure it out, and here's the video.
And NOTE: This only matters if you want to CHANGE the password of the keystore and keep the keystore. If all you need to do is add a server certificate to the keystore for a new web connection, you can simply use the "Get Certificate" button in the HTTP Server Connector to get the server's certificate and add it to the keystore.
ldapmodify: invalid format (line 5 of entry: cn=schema)After a bit of pain, I figured out that the whitespace in the lines are the problem. You need to either concatenate the continued lines together OR have some white space at the front of the continued lines. Additionally, there should be a space in betwee "oid" and "DBNAME". So if you change the file to the following, you will no longer get the error:dn: cn=schema changetype: modify add: attributetypes attributetypes: ( myAttribute-oid NAME ( 'myAttribute' ) DESC 'An attribute I defined for my LDAP application' EQUALITY 2.5.13.2 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 {200} USAGE userApplications ) - add: ibmattributetypes ibmattributetypes: ( myAttribute-oid DBNAME ( 'myAttrTable' 'myAttrColumn' ) ACCESS-CLASS normal LENGTH 200 )What about updating the objectclass?
That's what I was wondering! Simply adding an attribute doesn't really help you much until you add it as a MUST or a MAY attribute to an objectclass. IBM has an almost complete guide to doing that here, But it is incomplete. For one thing, the format of the data is wrong again. The long attribute values should all be on a single line, like this:dn: cn=schema changetype: modify replace: objectclasses objectclasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'Defines entries representing people in an organizations enterprise network.' SUP 'organizationalPerson' Structural MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ pager $ photo $ preferredLanguage $ roomNumber $ secretary $ uid $ userCertificate $ userSMIMECertificate $ x500UniqueIdentifier $ mytest ) )Additionally, where did that value for "objectclasses" come from?? Well, that came from this command:ldapsearch -b cn=schema -s base objectclass=* objectclasses | grep \'inetOrgPerson\'Running that, you will get a result similar to:objectclasses=( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'Defines entries representing people in an organizations enterprise network.' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ preferredLanguage $ roomNumber $ secretary $ uid $ userCertificate $ userPKCS12 $ userSMIMECertificate $ x500UniqueIdentifier ) )Modify that to include your new attribute, then put that into the LDIF file. Then run idsldapmodify to import that LDIF file into your server. After that, you'll have your new attribute added to the inetOrgPerson objectclass.
IDI Version 10 ships with PKCS12 keystores rather than JKS keystores, but the file names still end with .jks, which can be quite confusing, especially if you're still running on an OS that has an older version of java as the system java. If you have your shell configured with the defaults and you just run something like:
keytool -list -keystore testserver.jks -v
You'll get the following error:
keytool error: java.io.IOException: Invalid keysstore format
java.io.IOException: Invalid keystore format
...
The simple fix for this is to provide the full path the the IDI-provided keytool command, such as:
/opt/IBM/TDI/cev10/jvm/jre/bin/keytool -list -keystore testserver.jks -v
Which will show you details about all of the certificates in the testserver.jks keystore.
FYI: the default password for testserver.jks is "server" and for serverapi/testadmin.jks, it is "administrator"
The documentation on this topic is slim on the gory details, so I figured I would write a little bit about it.
Keeping it simple, you should always start the ibmdisrv or ibmditk processes with the "-s" flag to specify the solution directory to use. If you don't do this, then you're just using whatever happens to be set in your environment, which could lead to quite a bit of confusion. As an example, you could have your CE (the eclipse IDI GUI) running with a DIFFERENT solution directory than your Default ibmdisrv process. This could lead to a case where properties that resolve perfectly in the GUI don't resolve when you go to run an AL. You can avoid this by always using full paths to properties files, but then that makes your solutions much less portable.