Potato Peelings

Getting Sun Secure Global Desktop 4.41 applications to launch on OpenSolaris hosts.
[Read More]

So you've got your hands on a copy of SGD 4.41 and are eager to try out some new stuff, well let me give you a few pointers.

Active Directory integration using SSL security without Client Certificates

In certain environments it is necessary to connect to a server in an Active Directory forest using SSL. In the past this has been possible in SGD by using a client certificate to authenticate your connection. Now it is possible to configure SGD to use Active Directory SSL security and still authenticate using a username and password (and kerberos). This is only recommended if you really need it.

To start using SSL, add the CA certificate of the Active Directory server(s) into SGD's truststore:

# keytool -import -file cacertfile.pem -alias myadserverca \
    -keystore /opt/tarantella/bin/jre/lib/security/cacerts \
    -storepass changeit 

Tell SGD to use SSL:

# tarantella config edit --tarantella-config-ad-usessl 1

Restart your server and that's it. Your AD LDAP connections are now made over SSL. For this to work, you need to make sure SGD can access the LDAPS ports on your AD servers. These are 3269 for Global Catalogs and 636 for Domain Controllers.

Assign applications to LDAP users using Extensible LDAP Searches

SGD has always had support for Extensible LDAP searches, only without the DN component matching ability. 4.41 contains the DN component matching functions. Here are a few examples:

You want to assign an application to all users below the "ou=Managers" organizational unit in your LDAP directory. You can do this with the following LDAP Search:

(ou:dn:=Manager) 

You want to assign an application to all users who are part of the domain managers.example.com. You can use the following LDAP Search:

(&(dc:dn:=managers)(dc:dn:=example)(dc:dn:=com))

I'll cover Partial LDAP Directory Mirroring and Improved AD Logging in my next post.

Hope everyone has a good weekend.

-- MPH

It feels like an absolute age since I last dumped my brain to digital paper. Partially to do with how busy we've been with the next release of SGD and partially due to the fact that I've had very little "ready" to print.

Just to give you a summary of my year so far: I've been 6000 miles aways and back again (JavaOne), seen my daughter turn one year old, added some new tools to my toolbox (BTrace), learned a few new tricks (JavaFX, BTrace, Ruby), fixed a handful of bugs, started a few new projects, completed some others...... the list goes on. I'm going to try to summarize all this over the next few weeks.

First thing I want to mention is the next release of SGD..... 4.41. I can't comment on an official release date as that's not my job, but I can mention some of the Active Directory and LDAP integration advances that will be coming.

New stuff:

• Active Directory integration using SSL security without Client Certificates
• Assign applications to LDAP users using Extensible LDAP Searches
• Partial LDAP Directory Mirroring
• Improved Active Directory logging using new server/ad log filters
  

Fixes

• Active Directory logins with expired passwords now prompt correctly for new password.
• Active Directory service discovery now times out using --tarantella-config-ldap-discovery-timeout.
• More reliable cache --flush command when flushing connection and lookups caches.
• More reliable Active Directory service fail-over when using SSL security.
  

Hopefully those of you that use Active Directory/LDAP integration will appreciate some of these and will keep an eye out for my next post that will contain some examples of why/how you might use the new features.

Until then, thanks and good night,

-- MPH

As JDK 1.6.0u4 has just been released to the public, it is now possible to resolve the Active Directory password expiry bug that a few people have pointed out on the forums.

The problem was caused by the JRE incorrectly reporting the "User must change password" response from Active Directory, meaning SGD never triggered the "New Password" prompt to the user.

This bug is resolved in 1.6.0u4 and I have just ran a few tests to be sure the prompts are given and passwords can be changed etc. So far, so good. The next thing is to tell everyone else what needs to be done to upgrade, so here goes:

Firstly, download the JDK from here. Depending on the platform/package type you have downloaded, install or unpack the contents.

Next, copy (or move) the unpacked/installed JDK into your SGD installation's bin directory. By default this is /opt/tarantella/bin. You should now have a new bin/jdk1.6.0_04 directory. Change the ownership of bin/jdk1.6.0_04 as follows:

 chown -R ttasys:ttaserv /opt/tarantella/bin/jdk1.6.0_04

Once permissions are correct we need to add in SGD's security provider to the JDK's security providers list. Edit /opt/tarantella/bin/jdk1.6.0_04/jre/lib/security/java.security,  add this line to the list of security providers:

 security.provider.9=com.sco.cid.security.jceprovider.TtaProvider

If there is already a security.provider.9 entry then replace the 9 with next available lowest number.

Now we have a configured JDK it is just a matter of telling SGD to use it. Stop the SGD server and make sure there are no rogue java processes owned by ttasys. If there are, kill them off.

The JDK location is configured in /opt/tarantella/var/javaenv. Either take a backup of this file or comment out the existing JHOME declaration (by default on line 2). Add the following line in-place of the exiting JHOME declaration:

 JHOME=/opt/tarantella/bin/jdk1.6.0_04/jre export JHOME

For those that want consistency, you can also tell the Tomcat server to use the new JDK by changing JAVA_HOME in /opt/tarantella/webserver/tomcat/<version>/bin/catalina.sh. Set it to the location of the new JDK:

JAVA_HOME="/opt/tarantella/bin/jdk1.6.0_04"

And that's it. Start your SGD server (and restart tomcat if you changed catalina.sh) and feel safe in the knowledge that it is using the latest edition of Java.

Any feedback on experiences of both the upgrade and use of the new JDK are welcomed. We have not carried out any official tests of SGD using JDK1.6.0_04. It is not officially supported unless this upgrade has been recommended to you by our support team. So if anything has been broken as a result of the upgrade, please bring it to our attention and we will look at it for when we officially add the new JDK to our product.

Anyone who is upgrading the JDK to fix the AD password expiry bug should keep in mind that their krb5.conf file will need a kpasswd_server entry for any domains that require password updating from SGD.

To downgrade back to the original JDK simply restore the javaenv file to it's original state, or at least change JHOME back it's original value.

Hopefully this has been of some use to someone.

Goodnight,

-- MPH

Over the last week I've had a number of discussions regarding LDAP Searches and how SGD evaluates them when generating DSI webtops. The general belief was that SGD issues the search to the LDAP server and checks the user is in the results. This is NOT the case. 

As SGD already has the user's attributes from the LDAP Server, the evaluation of the LDAP search is carried out by SGD. This evaluation is based on the rules defined in RFC2254, therefore any LDAP implementation specific queries will not result as expected.

Should SGD provide the administrators with a choice? Use the RFC2254 local evaluation engine or allow queries to be passed through to the LDAP server for evaluation. The latter will always include the overhead of a round trip to the LDAP server, but maybe this is not a problem in all cases. I'd be interested to know what people think about this so add a comment to this post, it might make all the difference.

That's it for now. Hope everyone has a great festive break and I'll be back next year with more SGD related postings.

-- MPH 

 

I've been meaning to put keyboard to weblog for sometime now but have never really had anything of importance to discuss. Over the last few weeks however, things have changed and a whole host of topics have come to light. As I'm not planning to cover everything in this initial "intro" entry, I will give anyone who is interested a "heads up" on what I'm planning to unleash.

First off, a quick hello and introduction is in order. I'm Mr Potato Head, a lowly engineer working in the Sun Secure Global Desktop Software Engineering Team. By lowly I don't want to give the impression that this is a boring place to be. There's a lot of interesting stuff going on over here in tropical Yorkshire (I think it's -1°C today) which I hope I'll get a chance to blog about over the next few months.

Here's the list of postings that I'm hoping to get out by Jan-Feb next year:

Updating SGD's JDK and JRE - This has come to light as a "AD user password expiry" bug that is present in our 4.31 and 4.40 packaged JDKs will be fixed in the forthcoming JDK 1.6.0u4 release. We've tested an EA version of u4 and the bug has been fixed. I'm going to hold back on this post until JDK 1.6.0u4 is officially available on java.sun.com.

SGD on Ubuntu "Feisty" Server - I've recently installed SGD on my own Ubuntu "Feisty" Server so thought other may benefit from my experiences here.

SGD Webservice Client - To make development testing the product easier I've been using the webservices to automated testable scenarios. Hopefully I'll get a chance to write a bit about this.

SGD Array Resilience - As we've been working on making SGD Arrays even more robust I thought I'd write about the work that we've done so far. As we're planning initial testing for Jan-Feb next year, that will probably be the best time to enter into a discussion.

SGD, LDAP and Active Directory - There are a number of minor bugs associated with LDAP and Active Directory which I'd like to mention and let everyone know what we are doing about them. There'll probably be a number of entries on this topic.

Like I said originally, I'm an engineer so none of my blog entries have any official backing, they are simply my view on what is going on in the SGD Engineering Camp. Time permitting, I'm hoping to get the first useful entry written before the new year so until then......

Over and out.

-- MPH