Monthly Archives: May 2010

Set up SSH host-based authentication between OpenSolaris and Solaris 10

Setting this up was way more hassle than it should have been thanks to some pretty ambiguous documentation.

I am using an OpenSolaris snv_134 x64 client to connect to a Solaris 10 u8 x64 server without the use of a password. Before starting, make sure that you have identical user accounts on both the server and client, and that hostname lookups are functioning normally. Also note that if you cock this up you run the risk of locking yourself out of SSH logins to the system.

(Official docs are at: http://docs.sun.com/app/docs/doc/816-4557/sshuser-12?a=view)

 

1) On the client, add the following to /etc/ssh/ssh_config:

HostBasedAuthentication yes

 

2) On the server, add the following to /etc/ssh/sshd_config:

HostBasedAuthentication yes

 

3) On the server, create the file /etc/ssh/shosts.equiv (if it does not exist) and add the hostname(s) of the authorised client(s). If you are using DNS, then use the DNS host name of the client, for example:

afterburner, or, afterburner.example.com

 

4) Set IgnoreRhosts to no in the server’s /etc/ssh/sshd_config file

 

5) Set PasswordAuthentication to no in the server’s /etc/ssh/sshd_config file

 

6) Set PAMAuthenticationViaKBDInt to no in the server’s /etc/ssh/sshd_config file

 

7) On the server, create the file /etc/ssh/ssh_known_hosts (if it does not exist)

 

8) Copy the host RSA public key from the client (on OpenSolaris snv_134 x64 this is /etc/ssh/ssh_host_rsa_key.pub) into the /etc/ssh/ssh_known_hosts file on the server

 

9) Edit the host RSA public key entry in /etc/ssh/ssh_known_hosts such that the first field in the file is the host name of the connecting client. If you are using DNS, then use the DNS host name of the client, for example:

afterburner, or, afterburner.example.com

ssh_known_hosts file

 

10) On the server, restart the ssh service:

# svcadm -v restart ssh

 

Done. Now test:

$ ssh ledstorm
Last login: Wed May 26 21:41:30 2010 from afterburner
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$
Advertisements

Google opens VP8(!!)

http://www.webmproject.org/

Huge news, and major respect to Google – in spite of all their privacy cock-ups of late – for following through with this. Ars Technica has an excellent assessment and summary of this:

http://arstechnica.com/web/news/2010/05/google-opens-vp8-codec-aims-to-nuke-h264-with-webm.ars

 

Some choice excerpts:

“Today, Google, Mozilla, and Opera announced the launch of the WebM Project. The goal of the project is to develop a high-quality, open-source, royalty-free video format suitable for the Web.”

“Nightly builds of Mozilla and Chromium…will include WebM support starting today.”

“…WebM is set to rapidly become the most widely supported standard for Web video. Firefox and Chrome together command about 35 percent of the browser market, which gives them more share than all the current H.264-supporting browsers together…”

 

And, of course:

“Apple …due to the company’s commitment to H.264, is likely to be even less keen to include support for the new codec.”

So, let’s see how committed Apple really are to an open standards-based web…

New AMD six-core desktop kit

Six cores on the desktop, for a grand NZD:

http://pbtech.co.nz/index.php?item=WKSPB1265

With all the fruit, including the choice bits which Intel tend to leave off at the same price point.

Do Want.

JSPWiki on OpenSolaris / Glassfish

I’m now using JSPWiki for internal documentation of the various projects and stuff I’m working on.

Installing on OpenSolaris snv_134 x64 with Glassfish 2.1 was as simple as uploading the relevant .war file from the JSPWiki installation packages using the Glassfish admin BUI (follow the “Easy Install” section here.). Just make sure that the Glassfish Context Root matches the base URL set when running the JSPWiki installer. For example, if my JSPWiki base URL is http://127.0.0.1:8080/ITProjects:

JSPWiki installer - base URL

JSPWiki on Glassfish - Context Root

“Open Source vs. Jive”

I couldn’t help but notice this, hot on the heels of Jive Software’s brief offensive against Open Source

Spotted in the OpenSolaris forums site restructuring pages:

“The forum software currently used on opensolaris.org is Jive. Unfortunately this is not open source, so it cannot be made freely available to the OpenSolaris community. It is also a source of frequent complaints about the site, and therefore needs replacing…”

I’d love to know more about the nature of these “frequent complaints”…

Use OpenDS for Thunderbird LDAP Address Book data

Trey Drake at Sun Microsystems has a quick little post for trying this with Apple Address Book:

http://blogs.sun.com/treydrake/entry/mac_address_book_and_opends

“Works like a charm” indeed, and doing the same with Thunderbird proves to be just as easy 🙂 Using the OpenDS setup instructions outlined in my Apache Roller post, and using Thunderbird 3.0 on OpenSolaris snv_134 x64, one simply configures an LDAP address book like so:

OpenDS LDAP Address Book in Thunderbird

By default OpenDS enables anonymous read/search access to the directory, so we don’t need to authenticate.

Additionally, I’ve set up my OpenDS server to run automatically as a service using SMF – the guide which I followed to achieve this is here:

https://docs.opends.org/2.2/page/ManagingTheDirectoryServerAsAnSMFServiceOpenSolarisOnly

The only problem I encountered after configuring the above was getting the ldap user to access the OpenDS control panel GUI without X server security errors. One has to use the xhost command to grant access to the X server for the ldap user:

$ xhost  
access control enabled, only authorized clients can connect
SI:localuser:gdm
SI:localuser:root

$ pfexec xhost +SI:localuser:ldap
localuser:ldap being added to access control list

$ xhost                          
access control enabled, only authorized clients can connect
SI:localuser:ldap
SI:localuser:gdm
SI:localuser:root

After which I could launch the OpenDS control-panel application as the ldap user fine – although I haven’t determined yet how to make this persistent across reboots or desktop logins.

Using Apache Roller with OpenDS for LDAP authentication

This is a basic guide and is more a set of self-help notes while I learn about LDAP. Even so, at the end of this you’ll have an idea about how to securely authenticate to Roller with user account information held in an OpenDS LDAP directory.

We are using OpenDS v2.2, and an OpenSolaris system running Apache Roller as described in detail in my post here. This how-to assumes you have a freshly installed instance of Roller as described in that link, and have created the initial Roller administrator account with a username of “admin”.

 

Install OpenDS v2.2

The OpenDS installer is a thing of beauty, and a model for how easy software download and installation could be. Matter of fact, with its built-in Java monitoring and administration control panels, the whole package is pretty darn cool.

Go to http://www.opends.org/ and click the “Get 2.2″ now!” link. (make sure you have a recent JRE installed and a decent internet connection).

You’ll be presented with the OpenDS QuickSetup Welcome screen. We want to install a new server instance:

OpenDS QuickSetup Welcome screen

Enter your installation path, and under “LDAP Secure Access”, click the “Configure…” button; in the following screen enable SSL access, and generate a self-signed certificate. All other settings are fine at their defaults:

OpenDS Server Settings

OpenDS configure SSL

We want a standalone server:

OpenDS standalone server

For our Directory Data, the default Directory Base DN of dc=example,dc=com is fine. We also only want to create the base entry for now:

OpenDS Directory Data

Review the settings, and click “Finish” to complete. Once OpenDS has worked its magic, launch the OpenDS control panel, and select the local server instance to manage:

OpenDS installation finished

OpenDS control panel login

 

Create LDAP account information in OpenDS

We’ll now quickly populate our OpenDS directory with some very basic user information.

In the OpenDS Control Panel main view, click the “Directory Data” disclosure arrow on the left-hand of the window, and select “Manage Entries”. In the “Manage Entries” window that appears, select “Entries” on the menu bar, then select “New Organizational Unit”. Name the new OU “People”:

OpenDS - create People OU

Select the newly created “People” OU, and from the “Entries” menu, select “New User…”. Enter the information as follows, noting that the value for “User ID” (UID) will be the same as the Roller account username (in this case, the initial Roller administrator account):

OpenDS - create an admin user

Create additional entries in the same way if you like:

OpenDS - create additional users

 

Import the OpenDS SSL certificate into the system and Glassfish domain keystores

We are setting this up with secure connections all ’round, so Roller needs to trust OpenDS by using OpenDS’ certificate. When installing OpenDS, we generated a self-signed certificate – so we simply locate this and import it into the relevant keystores. We use the keytool command to do this.

I’ve installed OpenDS to /opt/OpenDS, so the OpenDS keystore is located at /opt/OpenDS/config/keystore.

The location of the keystores for the system, and for the Glassfish domain containing the instance of Roller are located respectively at:

/usr/java/jre/lib/security/cacerts
/var/appserver/domains/domain1/config/cacerts.jks

 

Let’s view the contents of the OpenDS keystore:

$ pfexec keytool -list -v -keystore /opt/OpenDS/config/keystore
Enter keystore password:  

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: server-cert
Creation date: 3/05/2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=afterburner, O=OpenDS Self-Signed Certificate
Issuer: CN=afterburner, O=OpenDS Self-Signed Certificate
Serial number: 
Valid from: Mon May 03 16:38:02 NZST 2010 until: Wed May 02 16:38:02 NZST 2012
Certificate fingerprints:
	 MD5:  
	 SHA1: 
	 Signature algorithm name: SHA1withRSA
	 Version: 3

 

Now, export the OpenDS certificate to a file:

$ pfexec keytool -export -alias "server-cert" \
-keystore /opt/OpenDS/config/keystore -file /tmp/server-cert.cer
Enter keystore password:  
Certificate stored in file /tmp/server-cert.cer

 

Then import the exported certificate into the Java system keystore:

$ pfexec keytool -import -v -trustcacerts -alias "server-cert" \
-keystore /usr/java/jre/lib/security/cacerts -file /tmp/server\-cert.cer 
Enter keystore password:  
Owner: CN=afterburner, O=OpenDS Self-Signed Certificate
Issuer: CN=afterburner, O=OpenDS Self-Signed Certificate
Serial number: 
Valid from: Mon May 03 16:38:02 NZST 2010 until: Wed May 02 16:38:02 NZST 2012
Certificate fingerprints:
	 MD5:  
	 SHA1: 
	 Signature algorithm name: SHA1withRSA
	 Version: 3
Trust this certificate? [no]:  yes
Certificate was added to keystore
[Storing /usr/java/jre/lib/security/cacerts]

 

And do the same for the Glassfish Roller domain keystore:

$ pfexec keytool -import -v -trustcacerts -alias "server-cert" \
-keystore /var/appserver/domains/domain1/config/cacerts.jks \
-file /tmp/server\-cert.cer 
Enter keystore password:  
Certificate already exists in system-wide CA keystore under alias server-cert
Do you still want to add it to your own keystore? [no]:  yes
Certificate was added to keystore
[Storing /var/appserver/domains/domain1/config/cacerts.jks]

 

 

Configure Roller for LDAP authentication

This involves modifications to the Roller security.xml file to enable LDAP logins, as well as a small change to the roller-custom.properties file. The security.xml file is located (on my system) at /opt/Roller/webapp/roller/WEB-INF. Let’s modify this file first.

 

Under the AUTHENTICATION section of security.xml I’ve added /roller-ui/user.do*=register to the value list for the filterInvocationInterceptor bean. Then under the authenticationManager bean I’ve commented out daoAuthenticationProvider and uncommented ldapAuthProvider.

A copy of this section of my security.xml file follows; hover your mouse over the top-right of the box and select “view source” for the full view:


    <!-- ======================== AUTHENTICATION ======================= -->
    
    <bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
        <property name="authenticationManager" ref="authenticationManager"/>
        <property name="accessDecisionManager" ref="accessDecisionManager"/>
         <property name="objectDefinitionSource">
            <value>
                PATTERN_TYPE_APACHE_ANT
                /roller-ui/login-redirect**=admin,editor
                /roller-ui/profile**=admin,editor
                /roller-ui/createWeblog**=admin,editor
                /roller-ui/menu**=admin,editor
                /roller-ui/authoring/**=admin,editor
                /roller-ui/admin/**=admin
                /roller-ui/user.do*=register
                /rewrite-status*=admin
            </value>
                <!-- Add this to above list for LDAP/SSO configuration -->
                <!-- /roller-ui/user.do*=register -->
        </property>
    </bean>

    <bean id="authenticationManager" class="org.acegisecurity.providers.ProviderManager">
        <property name="providers">
            <list>
                <!-- <ref local="daoAuthenticationProvider"/> -->
                <ref local="ldapAuthProvider"/>
                <!-- Uncomment this for CAS/SSO configuration <ref local="casAuthenticationProvider"/> -->
                <ref local="anonymousAuthenticationProvider"/>                
                <!-- rememberMeAuthenticationProvider added programmatically -->
            </list>
        </property>
    </bean>

 

Next, proceed to the LDAP AUTHENTICATION section of security.xml, and uncomment the sample block of code visible there. Most of the code is fine as-is, but we set the constructor-arg value for the initialDirContextFactory bean to the URL/BaseDN of our LDAP server, and the values for managerDn and managerPassword to our OpenDS directory administrator username and password respectively.

A copy of this section of my security.xml file follows; hover your mouse over the top-right of the box and select “view source” for the full view:


    <!-- ===================== LDAP AUTHENTICATION ==================== -->

    <bean id="initialDirContextFactory" class="org.acegisecurity.ldap.DefaultInitialDirContextFactory">
        <constructor-arg value="ldaps://localhost:1636/dc=example,dc=com"/>
        <property name="managerDn" value="cn=Directory Manager"/>
        <property name="managerPassword" value="somepassword"/>
    </bean>
   
    <bean id="ldapUserSearch" class="org.acegisecurity.ldap.search.FilterBasedLdapUserSearch">
        <constructor-arg index="0" value=""/>
        <constructor-arg index="1" value="uid={0}"/>
        <constructor-arg index="2" ref="initialDirContextFactory"/>         
        <property name="searchSubtree" value="true"/>           
    </bean>     
    
    <bean id="ldapAuthProvider" class="org.acegisecurity.providers.ldap.LdapAuthenticationProvider">
        <constructor-arg>
            <bean class="org.acegisecurity.providers.ldap.authenticator.BindAuthenticator">
                <constructor-arg ref="initialDirContextFactory"/>
                <property name="userSearch" ref="ldapUserSearch"/>
            </bean>
        </constructor-arg>
        <constructor-arg ref="jdbcAuthoritiesPopulator"/>
        <property name="userCache" ref="userCache"/>
    </bean>    
    
    <bean id="jdbcAuthoritiesPopulator" class="org.apache.roller.weblogger.ui.core.security.AuthoritiesPopulator">
        <property name="defaultRole" value="register"/>       
    </bean>

 

Now, add the following entry to roller-custom.properties (which resides on my system at /var/appserver/domains/domain1/lib/classes):

users.sso.enabled=true

A shout out to Trey Drake from Sun Microsystems who originally blogged about this at http://blogs.sun.com/treydrake/entry/opends_roller_integration.

 

Log in to Roller using LDAP authentication

The caveat here is that Roller user accounts must already exist for successful LDAP authentication; LDAP+Roller will not provision them automatically, at least not with this simple setup.

Restart the Glassfish Roller domain (and possibly the Roller MySQL database as well for completeness) and you should now be able to log in to Roller with the username admin, using the LDAP password specified when you created the corresponding admin account in OpenDS.

Additional Roller user accounts you create as the Roller admin user (using the Roller admin BUI) can use LDAP for authentication, provided the username you specify for the Roller user account is the same as the UID (User ID) for the corresponding OpenDS entry.

PlayOgg – because freedom matters

PlayOgg

What’s new in Apache Roller 5.0

Dave Johnson, the primary developer behind the Apache Roller blogging platform, has posted a “what’s new” list for the upcoming Apache Roller 5.0 release:

https://cwiki.apache.org/confluence/display/ROLLER/What%27s+new+in+Roller+5.0

Lots of incremental improvements to an already solid application – good stuff.