UTF-8 characters import into LDAP (TDS)

Related to previous post is the following problem: how to batch process multiple LDAP entries based on LDIF files, for entries containing UTF-8 characters (like polish specials)?
The way you should deal with them is quite similar, but you need to do one additional step: use Base64 encoding to pass UTF-8s to LDAP.

So, if you find yourself facing the following problem:

• ldapmodify: no DN specified
• ldap_add: Invalid DN syntax (34)
          additional info: R004054 Invalid UTF-8 character found in string value (srv_explode_dn_int)

you need to do the following:

1. Prepare your data in a text file but before pasting/typing in set encodingo to UTF-8, eg:
   
   dn: cn=Kłak Szósty,ou=1,ou=2,O=myorg,C=PL
   cn: Kłak Szósty
   sn: 12345678901
   objectclass: person
   objectclass: top
   
2. Now, use any tool to encodee UTF-8 strings into Base64 to get something like:
   
   dn:: Y249S8WCYWsgU3rDs3N0eSxvdT0xLG91PTIsTz1teW9yZyxDPVBM
   cn:: S8WCYWsgU3rDs3N0eQ==
   sn: 12345678901
   objectclass: person
   objectclass: top
   
   and be sure that you've added second colon (:) before b64 values!!
   
   for Base64 encode I use N++ MIME plugin.
3. Having "based" your strings, now convert the file to ANSI (save as ANSI). This does not change the way it looks on the screen
   
4. Copy to the target system using "binary" transfer mode and use it as an input to ldap shell tools (ldapadd, ldapmodify)

It should now work nice and smooth. The tools of preference are still WinSCP and Notepad++ , of course (for encoding you need MIME plugin). Good luck!

UTF-8 characters in pdadmin (TAM 6.1)

Recently I came across the following problem: how to import LDAP users that have UTF-8 (Polish) characters into TAM with pdadmin? When you simply run pdadmin and use user import command, you will get the result as in following example:

user import elenaciezka "cn=Elena Ciężka,ou=1,ou=2,ou=3,O=myorg,C=PL"

Could not perform the administration request
Error: HPDMG0755W   The specified Distinguished Name (DN) does not exist. (status 0x14c012f3)

As you can easily add these users with Web Portal Manager, that means there is *the way* to do it with pdadmin, which is useful if you want to import more than ten-s of users...

A little googling and the solution to this problem is to use command files as input to pdadmin, which contain UTF-8 characters of your choice. but that's a little peculiar as you need to prepare the command file as ANSI type :)

So, that's what you need to do:

1. prepare command file, setting UTF-8 encoding first so you get:
   
   user import elenaciezka "cn=Elena Ciężka,ou=1,ou=2,ou=3,O=myorg,C=PL"
   
2. change the encoding to ANSI and you see:
   
   user import elenaciezka "cn=Elena Ciężka,ou=1,ou=2,ou=3,O=myorg,C=PL"
   
3. save the file (say: tam_import.txt) and copy it to your target system using binary mode (most safe in terms of transmission of some strange stuff)
   
4. before running pdadmin set shell to use your locale:
   
   export LANG=pl_PL.utf-8
   
   
5. and you can finally use your file:
   
   pdadmin -a sec_master -p your_password tam_import.txt
   

And that should be all. for file conversion you can use text editor of your choice, my preference is the ultimate Notepad++ (seriously guys, n++ is awesome!!) and for transfer any scp client (WinSCP, I prefer).

Good luck guys, and come back for more.

another blog, another idea

hello everyone.

I already had several attempts to start up my blog but honestly, I always lack commitment and regularity to post once some time.
I'm working as IT Specialist and almost every day I find these simple, little problems that seem an obstacle on my way to successful implementation. Usually after some digging in the net I come across the pieces of the puzzle that let me solve my issue. So here's my goal: I will post the whole puzzles here in simple steps.
I do hope they will be found useful by others who deal with similar stuff.

To sum up: stuff is mainly WebSphere family, TAM,TDS & TFIM. Particularly WS-Security and security integration. And yes, I'm and IBM employee.
So please remember that none of the statements posted on this blog are the official statement of IBM Company.