[under construction]
Introduction
Beginning with SGD version 4.40, a new web-based administration console was introduced. As a web application, the console is available to anyone with a web browser. While the usual authentication requirements still apply, some have expressed discomfort with making this so available, and have asked for some mechanisms to make it less so.
Below are some possible approaches to reducing the profile and/or increasing the security of the admin console. Note that if you're using a properly configured two-factor authentication system, these steps are probably redundant.
Method 1. Obscuring the Console Application
The problem some have is that the default landing page for SGD includes a link to launch the Administration Console, that is:
Some see this as an invitation to run the application, and some administrators want to prevent this. A really simple approach is to simply remove the Console link from the landing page. The Console is still available from the Administrator's webtop, and available to anyone that knows the URL, i.e.:
//servername/sgdadmin
To make this change, simply edit the following file(s) as appropriate:
$INSTDIR/webserver/apache/version/htdocs/webtop_en.html - English
$INSTDIR/webserver/apache/version/htdocs/webtop_fr.html - French
$INSTDIR/webserver/apache/version/htdocs/webtop_ja.html - Japanese
$INSTDIR/webserver/apache/version/htdocs/webtop_ko.html - Korean
$INSTDIR/webserver/apache/version/htdocs/webtop_zh_CN.html - Chinese (Simplified)
$INSTDIR/webserver/apache/version/htdocs/webtop_zh_TW.html - Chinese (Traditional)
Comment out (or delete) the appropriate lines, (lines 34-41 in the sample below)
29 <td><p>Log in to Sun Secure Global Desktop.</td> 30 </tr> 31 <tr> 32 <td colspan="3" width="20" height="10"><p></td> 33 </tr> 34 <!-- <tr> --> 35 <!-- <td><p><a href="/sgdadmin" alt="Launch the Sun Secure Global Desktop Admin istration Console" title="Launch the Sun Secure Global Desktop Administration Console">Launch the Sun Secure Global Desktop Administration Console</a></td> --> 36 <!-- <td> </td> --> 37 <!-- <td><p>The Sun Secure Global Desktop Administration Console.</td> --> 38 <!-- </tr> --> 39 <!-- <tr> --> 40 <!-- <td colspan="3" width="20" height="10"><p></td> --> 41 </tr> 42 <tr>
Method 2. Restricting Access to Specific IP Addresses
This method uses Apache to only allow access to the console application from specific client IP addresses. This is a fairly simple mechanism, but can be effective, if using static IP addresses.
<Location /sgdadmin> Order Deny, Allow Deny from All Allow from 192.168.1.107 </Location>
Wild-cards / sub-nets, and domain names are also possible selectors, see the Apache documentation on the "Allow" directive here.
Method 3. Protecting Console Application with Client Certificates
This method demands the user possess a digital client certificate signed by an appropriate Certificate Authority, to get to the admin console. If you're not already participating in a PKI-enabled environment, you can create your own local Certificate Authority (CA) to create and sign digital certificates, and distribute them to your administrators. Each administrator will install these client certificates in the web browsers of the machines they use. The SGD webserver will also be reconfigured to require client certificates, and only accept those signed by a particular Certificate Authority.
In the following example, a single admin certificate is created, (which could be shared by all administrators), but individual certificates would work in exactly the same way, as long as they're signed by the same CA. Note that this isn't integrated with the console login process, you still have to login as normal after providing the certificate.
The following example was worked on a standard Solaris 10 x86 system, adapt as necessary for other operating systems.
Step 1: Obtain / Install OpenSSL (if necessary):
# wget ftp://ftp.sunfreeware.com/pub/freeware/intel/10/openssl-0.9.8f-sol10-x86-local.gz .
# gunzip openssl-0.9.8f-sol10-x86-local.gz
# pkgadd -d openssl-0.9.8f-sol10-x86-local
# PATH=/usr/local/ssl/bin:$PATH
Step 2. Create a CA Private Key and Signing Certificate
# cd /opt/tarantella/var/tsp # mkdir client # chown ttasys:ttaserv client # cd client # openssl genrsa -des3 -out CA.key 2048 Generating RSA private key, 2048 bit long modulus ...+++ .................................................................................................+++ e is 65537 (0x10001) Enter pass phrase for CA.key: <Enter Pass phrase for the key> Verifying - Enter pass phrase for CA.key: <Re-enter Pass phrase> # openssl req -new -x509 -days 3560 -key CA.key -out CA.crt Enter pass phrase for CA.key: <Enter the Pass phrase from above> You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ---- Country Name (2 letter code) [AU]:<Enter Country Code> State or Province Name (full name) [Some-State]:<Enter State or Province Name> Locality Name (eg, city) []:<Enter City> Organization Name (eg, company) [Internet Widgits Pty Ltd]:<Enter org name> Organizational Unit Name (eg, section) []:<Enter org unit name, e.g. "SGD Client CA"> Common Name (eg, YOUR name) []:<Enter CN, e.g. "SGD Client CA"> Email Address []:<Enter email address> # chmod 770 CA.crt # chgrp ttaserv CA.crt
Step 3. Create a Client Private key and Certificate Signing Request (CSR)
# openssl genrsa -des3 -out sgdadmin.key 1025 Generating RSA private key, 1025 bit long modulus ........++++++ .......................++++++ e is 65537 (0x10001) Enter pass phrase for sgdadmin.key: <Enter/create pass phrase> Verifying - Enter pass phrase for sgdadmin.key: <Re-enter pass phrase> # openssl req -new -key sgdadmin.key -out sgdadmin.csr Enter pass phrase for sgdadmin.key: <Enter pass phrase from above> You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:<Enter country code> State or Province Name (full name) [Some-State]:<Enter State or Province> Locality Name (eg, city) []:<Enter locality/city> Organization Name (eg, company) [Internet Widgits Pty Ltd]:<Enter orgname> Organizational Unit Name (eg, section) []:<Enter OU name, e.g. "SGD Admin"> Common Name (eg, YOUR name) []:<Enter CN, eg. "SGDAdmin"> Email Address []: <Enter email address> Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Step 4. Sign it using the CA signing key created in Step 2
# openssl x509 -req -in sgdadmin.csr -out sgdadmin.crt -sha1 -CA CA.crt -CAkey CA.key -CAcreateserial -days 3560 Signature ok subject=/C=US/ST=State/L=City/O=orgname.com.com/OU=SGD Admin/CN=SGDAdmin/emailAddress=root@email.com.com Getting CA Private Key Enter pass phrase for CA.key: <Enter pass phrase for CA certificate>
Step 5. Convert to PKCS#12 Format
Note: "Export" password is given to Client Certificate recipient to import certificate
# openssl pkcs12 -export -in sgdadmin.crt -inkey sgdadmin.key -name "SGDAdmin Client Certificate" -out sgdadmin.p12 Enter pass phrase for sgdadmin.key: Enter Export Password: Verifying - Enter Export Password: <Enter export password>
Step 6. Transfer Client Certificate
Distribute the created client certificate (sgdadmin.p12) and the "Export Password" to the designated admin users. The user will then import / install the client certificate into their web browser.
For example, in Firefox: 
"Tools" >> "Options" >> "Advanced" >>"Encryption" >> "View Certificates" >> "Import"
Specify location of "sgdadmin.p12" and enter "Export Password" from above.
Step 7. Configure Webserver to Require Client Certificates
In $INSTDIR/webserver/apache/version/conf/httpd.conf
make the following addition inside the "SSL VirtualHost Context"; the precise location isn't critical, but immediately after the 'Location "/sgd"' is as good a place as any:
#<Location "/sgd">
# SSLOptions +StdEnvVars +ExportCertData
#</Location>
<Location /sgdadmin/*>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>
Also, uncomment/edit the line that for "SSLCACertificateFile", changing the location if necessary:
#SSLCACertificatePath /opt/tarantella/webserver/apache/1.3.36_mod_ssl-2.8.27_ope
nssl-0.9.8d_jk1.2.15_u1/conf/ssl.crt
SSLCACertificateFile /opt/tarantella/var/tsp/client/CA.crt
Step 8. Restart Webserver, and Test.
Using a web-browser with the properly installed client certificate, browse to _https://server/sgdadmin_.\\
If configured correctly, you should see a prompt like:
Click ok, and you should next see the administration console login prompt.
Sign up or Log in to add a comment or watch this page.