Công ty cổ phần công nghệ VSD

Công ty cổ phần công nghệ VSD ( http://vsd.com.vn) thành lập năm 2012. VSD được thành lập với mục tiêu cung cấp cho khách hàng những sản phẩm, giải pháp CNTT đáng tin cậy và hiệu quả cao.

 VSD luôn có những ý tưởng và tầm nhìn bắt kịp với sự phát triển về công nghệ thông tin, có những giải pháp để đáp ứng với nhu cầu thực tế. Với lực lượng cán bộ chuyên nghiệp, được đào tạo bài bản và có nhiều kinh nghiệm hoạt động trong lĩnh vực CNTT, chúng tôi luôn tự tin có thể mang đến cho các bạn sự hài lòng nhất thông qua các giải pháp, sản phẩm và dịch vụ của chúng tôi.
       Bằng sự nỗ lực của lãnh đạo và tập thể cán bộ VSD, chúng tôi sẽ phấn đấu hết mình vì sự phát triển CNTT của nước nhà, vì sự hài lòng của quý khách hàng. VSD cam kết sẽ luôn đem lại các sản phẩm, dịch vụ hiệu quả nhất, hỗ trợ vận hành, nhiệt tình giải đáp các thắc mắc của khách hàng 24/7.

Sản phẩm và dịch vụ của công ty VSD
Sản phẩm

Dịch vụ

ISA 2006 Authentication over HTTP

I implemented different ISA 2006 Reverse Proxy servers in conjunction with Microsoft Exchange 2003 or Windows Exchange 2007.
Today I configured ISA 2006 with Exchange 2007. I configured the Reverse Proxy server as I did always. And the connection from outside the network works perfectly. On the internal Exchange server I configured Basic and Integrated Authentication on the OWA virtual directory. The problem is that internal users now automatically log in to their webmail box when entering the URL from the Exchange server.
This is not the desired configuration, because internal users should be able to open other people’s mailboxes by logging in as that user. The customer also has an ISA 2006 on the internal network for forwarding proxy purposes.
I decided to publish Exchange 2007 on the internal ISA 2006 server as well. The configuration should use Form Based Authentication (FBA) over HTTP. After configuring and trying the connection, the user can’t access the ISA logon page. In the logging you find that Authentication over HTTP isn’t allowed.

Error Code: 403 Forbidden. ISA Server is configured to block HTTP requests that require authentication. (12250)

This is a default setting in ISA 2006 which can be disable. To allow Authentication over HTTP go to the Listener configuration. Go to the Authentication tab and Select Advanced. In the next tab enable the option Allow client authentication over HTTP. This option enables the using FBA over HTTP.

 booches.nl

Active Directory restores: How to restore deleted objects

Windows Server 2008 and Windows Server 2008 R2 allow you to restore deleted objects back to the Active Directory. In this article, I will demonstrate an Active Directory restore with a combination of authoritative and non-authoritative techniques.
A non-authoritative restoration is a process in which the domain controller is restored, and then the Active Directory objects are brought up to date by replicating the latest version of those objects from other domain controllers in the domain.
An authoritative restore is an operation in which the data that has been restored takes precedence over the data that exists on other domain controllers in the domain. When you perform an authoritative restore, the current versions of objects in the Active Directory are overwritten by the versions of the objects which were restored.
This process works the same way regardless of how you made the backup or where the data is being restored from. The Active Directory objects that have been restored are assigned a new version number, which ensures that the Active Directory replication process will overwrite the existing Active Directory objects with the objects that have been restored. This process is completely automated and it affects all of the domain controllers in the domain.
Performing the restoration
The restoration process is performed from the command line. To begin, you’ll need to know the name of the object that you plan to restore, as well as that object’s location within the Active Directory.
Because we are restoring an object that has been previously overwritten or deleted, we will have to perform an authoritative restore. That way the item that you have restored will not be overwritten by a newer copy during the Active Directory replication process.
However, we can’t just jump right in to an authoritative restoration, because the entire Active Directory would be rolled back to a previous state and defeat the purpose of performing a granular restoration.
To keep that from happening, we’ll perform a non-authoritative restore of the entire Active Directory. After doing so, we can make the restoration authoritative for the specific object that needs to be restored.
Performing a non-authoritative restoration
There are a variety of methods for performing the initial non-authoritative restore. The easiest way to complete this process is to stop the Active Directory Domain Services and then restore a valid system state. To stop the Active Directory Domain Services you will need to open an elevated command prompt and then enter the following command:
Net Stop NTDS
As you can see in Figure A, shutting down the Active Directory Domain Services causes several other dependency services to stop as well. The dependency services that are affected by this operation include:

Kerberos Key Distribution Center
Intersite Messaging
DNS Server
DFS Replication
Once the Active Directory Domain Services have been stopped, you can restore a System State backup. When the restoration process completes, you will likely be prompted to reboot your server. You should avoid rebooting because doing so will cause the Active Directory Domain Services to be restarted, which will cause your restoration to be overwritten.
Performing an authoritative restore
Before the server is rebooted, we need to tell Windows which Active Directory object needs to be restored authoritatively. This can be accomplished by using the NTDSUTIL utility. You can begin the process by entering the following commands:
Ntdsutil
Activate Instance NTDS
Authoritative Restore
Although not technically required, I recommend entering the LIST NC CRs command at this point. This command will list the various Active Directory partitions and their cross references. It allows you to validate that you are about to perform an authoritative restore within the correct Active Directory partition, as shown in Figure B.

Now it’s time to specify the object that needs to be restored. You can do so by using the Restore Object command. For example, suppose that you wanted to restore a user account named User1 that existed in the Users container in a domain named Contoso.com. To perform such a restoration, you would use the following command:
Restore Object “CN=User1,CN=Users,DC=Contoso,DC=com”
Wrapping it up
Now that you have marked the object that needs to be restored, the only thing that is left do is to restart the Active Directory Domain Services. This can be accomplished by entering the following command:
Net Start NTDS
When the Active Directory Domain Services start, the object that you restore will be replicated to the other domain controllers in the domain.
About the author: Brien M. Posey, MCSE, has previously received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and has been responsible for the Department of Information Management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.

How to Backup and Restore Active Directory on Server 2008

Have you ever accidentally deleted a user account or an OU in Active Directory and wished you could restore it?
I recently had a client call me after they installed updates and rebooted their server. They noticed after the reboot that there was a message that said “Active Directory is rebuilding indices. Please wait”.
Their Active Directory database had become corrupted from the updates. So what do you do? How can you restore AD?
Let’s talk about how to backup AD in Windows Server 2008 and how to restore it. Today I’ll show you:

• what you need to do to get your Server 2008 ready for backup
• how to backup Active Directory on Server 2008
• how to perform an Authoritative Restore of Active Directory
• how to perform Active Directory Snapshots

Prerequisites: Getting Server 2008 Ready for Backup

Before you can backup Server 2008 you need to install the backup features from the Server Manager.
1. To install the backup features click Start → Server Manager.


2. Next click Features → Add Features



3. Scroll to the bottom and select both the Windows Server Backup and the Command Line Tools



4. Click Next, then click Install

Backing up Server 2008 Active Directory

Now that we have the backup features installed we need to backup Active Directory. You could do a complete server backup, but what if you need to do an authoritative restore of Active Directory?
As you’ll notice in Server 2008, there isn’t an option to backup the System State data through the normal backup utility.



So what do we do? We need to go “command line” to backup Active Directory.
1. Open up your command prompt by clicking Start and type “cmd” and hit enter.
2. In your command prompt type “wbadmin start systemstatebackup -backuptarget:e:” and press enter.
Note: You can use a different backup target of your choosing
3. Type “y” and press enter to start the backup process.



When the backup is finished running you should get a message that the backup completed successfully. If it did not complete properly you will need to troubleshoot.



Now you have a system state backup of your 2008 Server!

Authoritative Restore of Active Directory

So now what if you accidentally delete an OU, group, or a user account and it’s already replicated to your other servers? We will need to perform an authoritative restore of the Active Directory object you accidentally deleted.
1. To do this you will need to boot into DSRM (Directory Services Restore Mode) by restarting your server and pressing F8 during the restart.
2.Choose Directory Services Restore Mode from the Advanced Boot menu.



3. Login to your server with your DSRM password you created during Active Directory installation.
4. Once you’re logged into your server and in DSRM safe mode, open a command prompt by clicking Start, type “cmd“, and press enter.
5. To make sure you restore the correct backup it’s a good idea to use the “wbadmin get versions” command and write down the version you need to use.



6. Now we need to perform a non-authoritative restore of Active Directory by typing “wbadmin start systemstaterecovery -version:04/14/2009-02:39“.
Note: The version of backup will vary depending on your situation. Type “y” and press enter to start the non authoritative restore.
7. Go grab some coffee and take a break while the restore completes.



8. You can mark the sysvol as authoritative by adding the –authsysvol switch to the end of the wbadmin command.



9. But if you want to restore a specific Active Directory object then you can use the ever familiar ntdsutil.
For this example we are going to restore a user account with a distinguished name of CN=Test User,CN=Users,DC=home,DC=local. So the commands would be:

ntdsutil
activate instance ntds
authoritative restore
restore object “cn=Test User,cn=Users,dc=home,dc=local”

Note: The quotes are required



10. Reboot your server into normal mode and you’re finished. The object will be marked as authoritative and replicate to the rest of your domain.

Using Active Directory Snapshots

There is a really cool new feature in Windows Server 2008 called Active Directory Snapshots. Volume Shadow Copy Service now allows us to take a snapshot of Active Directory as a type of backup. They are very quick to create and serve as another line of defense for your backup strategy.
With your server booted into normal mode open a command prompt by clicking Start, type “cmd“, and press enter.
We are going to use the ntdsutil again for creating the Active Directory snapshots. The commands are:

ntdsutil
snapshot
activate instance ntds
create
quit
quit

So now that you have a snapshot of AD, how do you access the data? First we need to mount the snapshot using ntdsutil. The commands are:

ntdsutl
snapshot
list all
mount 1 — (Note: You should mount the correct snapshot you need; for this example there is only 1.)
quit
quit

Your snapshot is mounted, but how do you access the data? We need to use the dsamain command to accomplish this. Then we need to select an LDAP port to use. The command is as follows:

dsamain –dbpath c:\$SNAP_200905141444_VOLUMEC$\WINDOWS\NTDS\ntds.dit –ldapport 10001

The result should look like this:



Now we need to go to Start, Administrative Tools, then Active Directory Users and Computers.
Right click Active Directory Users and Computers and select Change Domain Controller.



In the area that says < Type a Directory Server name [:port] here > enter the name of your server and the LDAP port you used when running the dsamain command.
For my example it would be: WIN-V22UWGW0LU8.HOME.LOCAL:10001



Now you can browse the snapshot of Active Directory without affecting anything else negatively.

Your AD Backup Strategy

It’s always good to have a solid backup plan for your Active Directory. You can use a combination of backup strategies or just one of these methods for backing up your Active Directory.
Make sure you tailor your Active Directory backup strategy to meet your company’s needs and make it easy to recover if disaster does strike.

Trainsignal.com

New email

Từ ngày 1/1/2012 do không tiếp tục làm việc tại Công ty CP tin học Tân Dân nên email NSNguyen@tandan.com.vn sẽ không còn tồn tại nữa. Mọi người có thể liên hệ theo địa chỉ NSNguyen@vsd.com.vn hoặc NguyenSTV@gmail.com

Moving an IIS SSL certificate to a Domino Keyring File

www.turtleweb.com

Today I had a support call from a customer who had bought an SSL certificate from Verisign to cover their entire domain.  Verisign had issued the certificate and it had been applied to their existing IIS servers however they now wanted to use it on their Domino web server as well. The scope of the certifier covered the Domino server (same wildcard domain) but Verisign wouldn't process another request from a Domino keyring file as they had already issued the key in response to the IIS request.  They agreed to cancel the IIS certificate and issue a new one for Domino but according to their tech support

"the use of the wildcard domain covers you for up to 10 servers so long as you can copy the same certificate between the servers.  As Domino and IIS are incompatible you have to buy a new certificate"

Well that seemed like a gyp so I decided to prove it could be done.  With the help of some related IBM technotes this is what I did to get it working.  

1. Created an exported pfx file from IIS
2. Went to a domino server and from a prompt found the directory  \domino\jvm\bin directory and ran the file "ikeyman" within it
3. Created a new Key DB file by browsing to the IIS exported pfx file and importing it as PKCS
4. Examined the imported certificate and noted the certificate settings such as Organisation, OU, L etc
5. Closed ikeyman
   
6. Created a new key ring file using the Secure Certificate Admin db on Domino
7. Gave it the exact same settings as the original IIS certificate noted down in step 4.
8. Installed the trusted root certificate into the key ring file
9. Copied the .kyr and .sth files to the server where ikeyman ran and where the PKCS file generated in step 3 was located
   
10. Downloaded gsk version of ikeyman to handle Domino key ring files from here ftp://ftp.software.ibm.com/software/lotus/tools/Domino/gsk5-ikeyman.zip
11. Extracted zip file to folder 'gsk' on server (folder can be called anything but no spaces)
12. Ran "gskregmod.bat Add" from command prompt within extracted folder
13. Launched the ikeyman from dos prompt in the newly extracted folder by typing "runikeyman.bat"
14. Chose Key Database File - Open and selected the kyr file I copied to the server in step 9
15. Go to Personal Certificates and click 'Import' then choose 'PKCS' and import the file generated in step 3

You should now have a .kyr file that contains the certificate and can be copied back to your destination Domino server along with its .sth file.

Configuring Microsoft Windows single sign-on on IBM WebSphere and Domino platforms

Introduction

Microsoft® Windows® single sign-on (SSO) allows the client in an Active Directory domain to be authenticated with the server, without being prompted for a user name and password, by leveraging Simple and Protected GSS-API Negotiation Mechanism (SPNEGO).

As of WebSphere® Application Server version 6.1, WebSphere provides the native support for Windows SSO by SPNEGO trust association interceptor (TAI). In version 7.0, WebSphere introduced better support for Kerberos, including the Kerberos mechanism for server-to-server authentication, as well Kerberos Web Authenticator.

As of version 8.5.1, Lotus Domino also started to support Windows SSO, though only on the Windows platform. In this article we introduce the Windows SSO configuration process on both the WebSphere and Domino platforms.

Common configurations

Windows SSO is based on Kerberos/SPNEGO protocols, and there are some steps we need to do on Kerberos before configuring either WebSphere Application Server or Lotus Domino. These common configurations include time synchronization and register service principal names (SPN) for the Web application.

Time synchronization

Timestamp is a critical factor in Kerberos authentication, and Kerberos requires the clocks of the involved hosts to be synchronized. Thus, the time of WebSphere Application Server or Domino in the SSO domain must be synchronized with the domain controller; otherwise, the Kerberos authentication will probably fail.

You can use the domain controller as the time server and run the Windows schedule task on all participating nodes to synchronize the time with the domain controller. For more information about how to use the domain controller as the time server, refer to the Microsoft Support document, “How to configure an authoritative time server in Windows Server.” For more information about running the Windows schedule task, see “Time synchronization may not succeed when you try to synchronize with a non-Windows NTP server in Windows Server 2003.”

For example, if lotus.ibm.com is both the domain controller and the Network Time Protocol (NTP) time server, then the TimeSyn.bat file would contain the following commands:

w32tm /config /manualpeerlist:lotus.ibm.com,0x8 /syncfromflags:MANUAL net stop w32time net start w32time w32tm /resync

Register SPN for Web applications

An SPN uniquely identifies a service in the Kerberos environment, and you must create an SPN to identify the Web application you want to enable with Windows SSO.

An SPN is typically composed of a service name, a fully qualified host name, and a realm name, for instance HTTP/lotus.ibm.com@IBM.COM. For Web applications, the service name is always HTTP. To register an SPN for the application, perform the following steps:

1. Log in to the Windows Domain Controller. You must know which server is the domain controller and have an administrative-level user name and password.
2. In Active Directory Users and Computers settings, select Action – New – User, to create a new service account that holds the SPN.
3. In the New Object - User window, enter an account name into the User logon name field and specify the domain in the corresponding field. For example, in the User logon name field, you could add appuser01, and in the domain field, you could select @ibm.com. Click Next.
4. Enter a password for the account in the Password field and Confirm password.
5. Select the User cannot change password and Password never expires check boxes. By preventing the password from expiring, you avoid having to recreate the keytab file (which you do in the next step) after the password is changed. Click Next and Finish, to save the new user information.
6. Map the SPN to the user account you just created, and then generate a keytab file by running the ktpass command on the domain controller. To run the ktpass utility, you must have Windows Support Tools installed (refer to Install Windows Support Tools for more details). Run the ktpass command as follows:

ktpass –princ <SPN> -out <path_to_keytab> -mapuser <account_name> -mapOp set –pass <account_password>

where you provide values for the following variables:

• <SPN>: The Kerberos SPN, which is composed of the “HTTP/” prefix and host name through which your Web application is accessed. Note that, in a network deployment, if your Web application is accessed via the IBM HTTP server, you should specify the host name of the HTTP server in SPN.
• <path_to_keytab>: File path in which you want to store the generated keytab file.
• <account_name>: The service account name you created in the previous step.
• <account_password>: Password associated with the service account. Note that, if you are configuring Windows SSO on WebSphere Application Server, you may optionally use the -rndPass option of ktpass utility, to generate a random password for better security.

For example:

ktpass -princ HTTP/lotus.ibm.com@IBM.COM -out c:\keytab 

-mapuser appuser01 -mapOp set -pass mypassword

You will need the keytab file when configuring Windows SSO for WebSphere Application Server.

Configuring SSO on WebSphere Application Server

In this section we describe the steps to enable Windows SSO on WebSphere Application Server, covering the configurations for both WebSphere Application Server V6.1 and V7.0. Because WebSphere Application Server is based on Java^TM Virtual Machine (JVM), the configuration process includes the steps to enable JVM with Kerberos and the WebSphere-specific configuration for inbound Web requests.

Create a Kerberos configuration file

To enable the JVM in WebSphere Application Server with Kerberos capabilities, you must create a Kerberos configuration file, which is normally named krb5.conf. The wsadmin utility in WebSphere Application Server can help you create this file.

NOTE: If you are in a network deployment environment, once you generate the configuration file, you must copy the configuration file to \java\jre\lib\security\krb5.conf on all servers in the cell.

On the wsadmin command line, enter the following command:

$AdminTask createKrbConfigFile 

{    

-krbPath <appserver>\java\jre\lib\security\krb5.conf 

-realm <REALM> 

-kdcHost <kdc_hostname> 

-dns <dns_hostname> 

-keytabPath <path_to_keytab>

}

where you provide values for the following variables:

• <appserver>: The path to the WebSphere Application Server root directory. The krbPath parameter defines where the resulting krb5.conf configuration file is stored. It is recommended to use \java\jre\lib\security\krb5.conf, as it is the default location for krb5.conf. However, if you want to use a non-default location for the krb5.conf file, you MUST specify a java.security.krb5.conf custom property for each JVM in the WebSphere Application Server cell.
• <REALM>: The Kerberos realm. Specify the realm in all uppercase letters.
• <kdc_hostname>: The name of the Active Directory key distribution center host. This name is typically the domain controller server.
• <dns_hostname>: The DNS server name of the domain controller server.
• <path_to_keytab>: The path to the keytab file. If you are in a network deployment environment, after you have generated the keytab, you must copy the keytab file to the same location on all servers in the cell, or use a unified path that points to a shared location on the network.

Listing 1 shows a sample configuration file.

Listing 1. Sample configuration file

[libdefaults]

default_realm = IBM.COM

default_keytab_name = FILE:C:\keytab

default_tkt_enctypes = des-cbc-md5 rc4-hmac

default_tgs_enctypes = des-cbc-md5 rc4-hmac

kdc_default_options = 0x54800000

# forwardable  = true

# proxiable  = true

# noaddresses = true

[realms]

IBM.COM = {

kdc = ibm.com:88

default_domain = ibm.com

}

[domain_realm]

.lotus.ibm.com = IBM.COM

Once the krb5.conf file is ready, you must restart WebSphere Application Server, to pick up the configurations and enable the underlying JVM with Kerberos capabilities. To verify the Kerberos configurations, type the following command to determine whether it can successfully get the Kerberos ticket:

<appserver>/java/jre/bin/kinit -k HTTP/lotus.ibm.com@IBM.COM

Create an HTML page

There are cases in which SPNEGO is not supported by browsers, or the clients have not logged into the Active Directory domain. In those cases, it is commonly desired that users can still log into the Web application with their user name and password via traditional form-based authentication.

Listing 2 shows a static HTML file that is used to redirect users whose Web browsers do not support SPNEGO to a non-SPNEGO-protected page that asks for authentication credentials. You should store the HTML file on a public place that is accessible to all the servers in the cell.

Listing 2. HTML file to redirect users

<!DOCTYPE HTML PUBLIC "-//W3C/DTD HTML 4.0 Transitional//EN">

<META HTTP-EQUIV="Content-Type" CONTENT="text/html">

<!--

Notes:

- This file should be served from an unprotected Web site. Alternatively, 

it can be loaded from the WebSphere Application Server file system.

- Any embedded graphics/javascript/css MUST BE loaded from an unprotected 

Web site.

- This file will be loaded after when the WebSphere Application Server is 

initialized. If changes to this file are necessary, the Application Server 

should be restarted.

- This file is returned whenever the SPNEGO TAI receives an NTLM 

token for ANY application in the cell. In other words, this file is 

generic for all applications. However, by using the JavaScript 

document.location, we can get the original URL, and redirect to that 

original URL with the "?noSPNEGO" text added - thus forcing the standard 

application userid/password challenge.

-->

<html>

<script language="javascript">

var origUrl=""+document.location;

if (origUrl.indexOf("noSPNEGO")<0) {

if (origUrl.indexOf('?')>=0) origUrl+="&noSPNEGO";

else origUrl+="?noSPNEGO";

}

function redirTimer() {

self.setTimeout("self.location.href=origUrl;",0);

}

</script>

<META HTTP-EQUIV = "Pragma" CONTENT="no-cache">

<script language="javascript">

document.write("<title> Redirect to "+origUrl+ " </title>"); 

</script>

<head>

</head>

<body onLoad="redirTimer()"/>

</html>

Enable SPNEGO TAI (version 6.1 only)

In WebSphere Application Server 6.1, SPNEGO TAI is used to perform the SPNEGO authentication. Perform the following steps to enable SPNEGO TAI in WebSphere Application Server:

1. Log into the WebSphere Application Server Integrated Solutions Console, if you have a standalone deployment, or into the Deployment Manager, if you have a network deployment.
2. Add custom properties to the Web Security settings by completing the following steps:

1. Expand Security and then select Secure administration, applications, and infrastructure. Expand Web Security, and then click Trust association.
2. Select Enable trust association.
3. Select Interceptors – com.ibm.ws.security.spnego.TrustAssociationInterceptorImpl – Custom properties.
4. Click New, to add each property, and then enter the details of the following properties:

com.ibm.ws.security.spnego.SPN1.hostName=<hostname> 

com.ibm.ws.security.spnego.SPN1.NTLMTokenReceivedPage=<TAIRedirectPage_location> 

com.ibm.ws.security.spnego.SPN1.spnegoNotSupportedPage=<TAIRedirectPage_location> 

com.ibm.ws.security.spnego.SPN1.filter=request-url!=noSPNEGO;<other_product_specific_filters>

com.ibm.ws.security.spnego.SPN1.filterClass=com.ibm.ws.security.spnego.HTTPHeaderFilter 

where

<hostname>: Name of the server from which your Web applications are accessed. It should be the same as the hostname used in the SPN.

<TAIRedirectPage_location>: File path to the HTML redirect file that you created in the previous step. The path should always start with file://. For example, file:///c:/share/TAIRedirect.html.

e. Click OK and then Save, to save each new custom property.

3. From the main Integrated Solutions Console, expand Servers, and then select Application servers.
4. Click the server name (for example, server1), expand Java and Process Management, and then select Process Definition – Java Virtual Machine – Custom Properties.
5. Add the custom property, com.ibm.ws.security.spnego.isEnabled = true.
6. Click OK and then Save, to save the custom property.
7. Repeat steps 3 through 6 for each server in the WebSphere Application Server cell.

Enable SPNEGO Web Authenticator (version 7.0 only)

SPNEGO Web Authenticator was introduced in WebSphere Application Server version 7.0 as the successor to SPNEGO TAI. Although SPENGO TAI still works, it is recommended to move to the SPNEGO Web Authenticator as it expand the capability of SPNEGO TAI.

To configure SPNEGO Web Authenticator, perform these steps:

1. Log in to the WebSphere Application Server Integrated Solutions Console if you have a standalone deployment, or into the Deployment Manager, if you have a network deployment.
2. Expand Security, select Global Security, and in the Authentication section, expand Web and SIP Security, and click SPNEGO Web authentication.
3. In the SPNEGO filter section, click New, to create a new filter and specify the following properties:

1. In the Host name field specify the name of the server from which your Web applications are accessed. It should be the same as the one used in SPN.
2. In the Kerberos realm name field specify the Kerberos realm name, for instance IBM.COM.
3. In the Filter criteria field specify request-url!=noSPNEGO;. Specific Lotus products might have different filter configurations.
4. In the Filter class field enter com.ibm.ws.security.spnego.HTTPHeaderFilter.
5. In the SPNEGO not supported error page URL and NTLM token received error page URL fields specify the shared location of the static HTML page created in Section 3.2 above. Note that the page URL should start with file://.
6. Put a check mark in the Trim Kerberos realm from principal name and Enable delegation of Kerberos credentials check boxes.

4. Click OK and Save, to save the new filter.
5. On the SPNEGO web authentication page, select the Dynamically update SPNEGO, Enable SPNEGO, and Allow fall back to application authentication mechanism check boxes.
6. In the Kerberos configuration file with full path field, specify the location of krb5.conf that was generated in Section 3.1 above.
7. You can leave the Kerberos keytab file name with full path field blank, to use the default keytab specified in krb5.conf, or specify the location of the keytab file generated in Section 2.2.

Authenticate on an unprotected URI (optional)

By default, SPNEGO TAI and SPNEGO Web Authenticator will authenticate the user once a URI is accessed, regardless of whether it requires authenticated access or not. However, in many cases, it is desirable to authenticate only when needed; for instance, when a user requests a protected page or resource.

The steps below describe how to avoid SPNEGO authentication on an unprotected URI by setting the performTAIForUnprotectedURI custom property.

To set a custom property that disables SPNEGO-TAI authentication when an unprotected URI is accessed in WebSphere Application Server 6.1:

1. Select Security – Secure administration, applications, and infrastructure – Custom properties.
2. Click New and enter the custom property:

com.ibm.websphere.security.performTAIForUnprotectedURI=false

3. Click OK and then click Save, to save the new property.

NOTE: This configuration works only from WebSphere Application Server version 6.1.0.21. Refer to IBM Support document #PK64013 for more detailed information.

To set a custom property that disables SPNEGO-TAI authentication when an unprotected URI is accessed in WebSphere Application Server 7.0:

1. Select Security – Global Security – Custom properties.
2. Click New and enter the custom property:

com.ibm.websphere.security.performTAIForUnprotectedURI=false

3. Click OK and then click Save, to save the new property.

NOTE: This configuration works only from WebSphere Application Server version 7.0.0.13. See IBM Support document #4027626 for more details.

Generate SPN for WebSphere Application Server (version 7.0 optional)

A Kerberos authentication mechanism for server-to-server communication was introduced in WebSphere Application Server 7.0. Although most of time Kerberos authentication is not required, we believe it is a good practice, to achieve a more secure deployment.

Below are the instructions to enable Kerberos authentication for server-to-server communications. The steps are generally the same as generating an SPN for WebSphere applications.

1. Log in to the Windows Domain Controller. You must know which server is the domain controller and have an administrative-level user name and password.
2. In Active Directory Users and Computers settings, select Action – New – User, to create a new service account that holds the SPN.
3. In the New Object - User window, enter an account name in the User logon name field and specify the domain in the corresponding field. For example, in the User logon name field, you could add wasuser01, and in the domain field, you could select @ibm.com. Click Next.
4. Enter a password for the account in the Password field and Confirm password.
5. Select the User cannot change password and Password never expires check boxes. By doing this, you avoid having to recreate the keytab file (which is done in the next step) after the password is changed. Click Next and Finish, to save the new user information.
6. Map the SPN to the user account you just created, and then generate a keytab file by running the ktpass command on the domain controller. To run ktpass command you must have Window Support Tools installed (refer to Install Windows Support Tools for more details). Run the ktpass command as follows:

ktpass –princ <SPN> -out <path_to_keytab> -mapuser <account_name> -mapOp set –pass <account_password>

where you provide values for the following variables:

• <SPN>: The Kerberos SPN for WebSphere Application Server, which is composed of the “WAS/” prefix and the host name of WebSphere Application Server in the cell.
• <path_to_keytab>: File path in which you want to store the generated keytab file.
• <account_name>: The service account name you created in the previous step.
• <account_password>: Password associated with the service account.

7. Repeat steps 2 through 6 for all WebSphere Application Server instances in the cell; you will get one keytab file for each WebSphere Application Server.
8. Merge all the generated keytabs into one keytab file created in the previous steps, using the ktab utility provided in JVM:

<appserver>/java/jre/bin/ktab -m <generated-keytab> <keytab-destination>

9. Once you merge the keytabs, use the klist utility to list the merged keytab file and verify whether all the merged keytab entries are shown in the output.

<appserver>/java/jre/bin/klist -k

10. If you are in a network deployment environment, once you merge the keytab, you must copy the merged keytab file to the same location on all servers in the cell, which will override the original keytab file created in Section 2.2.

Enable WebSphere Application Server for Kerberos (version 7.0 optional)

Beginning in WebSphere Application Server version 7.0, SPNEGO can be used for communications between the Deployment Manager and server nodes in WebSphere Application Server cells. It is a suggested configuration, and is not necessary in all deployments. To do this:

1. Log in to the WebSphere Application Server Integrated Solutions Console, if you have a standalone deployment, or the Deployment Manager, if you have a network deployment.
2. Expand Security, select Global Security, and click Kerberos configuration in the Authentication section.
3. In the Kerberos Authentication Mechanism section, specify the following:

1. In the Kerberos service name field, enter WAS as the service name, which is the default value.
2. In the Kerberos configuration file with full path field, specify the location of the krb5.conf that was generated in Section 3.1 above.
3. Leave the Kerberos keytab file name with full path field blank, to use the default keytab specified in krb5.conf, or specify the location of the keytab file generated in Section 3.6 above.
4. Place a check mark in the Trim Kerberos realm from principal name and Enable delegation of Kerberos credentials check boxes.
5. In the Kerberos realm name field, specify the Kerberos realm name, for instance IBM.COM. Click OK and Save, to save the changes.

4. In the Authentication section, click Kerberos and LTPA, if it is not already selected. Then click Apply.

Configuring on Lotus Domino

In this section, we introduce the steps to enable Windows SSO on Windows Domino as well as the Windows SSO solution for non-Windows Domino.

NOTE: Before configuring Windows SSO on Lotus Domino, make sure you have configured SSO based on Ltpa Token. For more details, refer to the wiki article titled, “Configuring single sign-on with an LTPA token on IBM WebSphere and IBM Lotus Domino platforms.”

Enable Windows SSO on Lotus Domino

In Lotus Domino, once you have configured SSO, you can quite easily enable Windows SSO in the Web SSO Configuration document, using these steps:

1. In the Domino Directory, select Configuration – Web – Web Configurations.
2. Double-click the Web SSO Configuration document, for example, Web SSO Configuration for LtpaToken.
3. In the Basic tab, set the Windows single sign-on integration (if available) option to be Enabled.
4. Click Save and Close to save the configurations.

Run Domino server with specific account

To successfully validate the Kerberos service tickets, the Domino server must be able to obtain the credential for the SPN generated for the Domino Web service, which means that the Domino server process must be run with the account that holds the SPN.

This is quite different from WebSphere Application Server, which uses a keytab file to hold the credential instead of retrieving it from runtime. There are two ways to achieve this. If your Domino server is registered as a Windows service:

1. In Windows, select Start – Control Panel – Administrative Tools – Services.
2. In the Windows services list, locate Lotus Domino Server, and double-click it to open the Properties dialog box.
3. In the Log on tab, specify the account that was chosen to hold the SPN in the previous steps and the password to that account.
4. Click OK to save the change and restart the Domino service.

Another option is to log in to Windows, using the account that was chosen to hold the SPN, and start the Domino service.

Mapping Kerberos log-on name to a Notes user (optional)

When configuring Windows SSO on Domino, normally you can opt to use Active Directory as the LDAP service for Domino using Directory Assistance; however, it is not a must. You can also use the Domino directory to map the Kerberos log-on name to a Notes user.

To enable the mapping, perform the following steps:

1. In the Domino Directory, select People – By Organization.
2. Select the Notes user from the right-hand-side list and click Edit Person.
3. On the Administration tab, specify the Active Directory (Kerberos) logon name for this Notes user, in the Client Information section.
4. Click Save & Close to save the changes.
5. Repeat Steps 1—4 for all users in the Domino Directory who have a Kerberos logon name.
6. Create a full-text index for the Domino Directory, to optimize searches of the Active Directory (Kerberos) logon name field.
7. Open the Notes.ini file in the Domino data directory and add WIDE_SEARCH_FOR_KERBEROS_NAMES=1 at the end of the configuration file.

NOTE: In this case, you SHOULD NOT enable Active Directory in Domino directory assistance.

Configure Windows SSO for non-Windows Domino (optional)

Due to the mechanism Domino used to retrieve service credentials, Windows SSO only works for Domino on the Windows platform. However, there is an open source project on www.openntf.org that provides a way to configure Windows SSO for non-Windows Domino.

The basic steps include enabling SSO between Windows Domino and non-Windows Domino, redirecting authentication requests to Windows Domino for Windows SSO, and then redirecting the requests back to non-Windows Domino. By this means, non-Windows Domino provides the Windows SSO capability by leveraging the capability on Windows Domino.

You can access the project, “SSO for Web for non Windows Servers,” for detailed information and instructions.

Browser configurations

For successful Windows SSO, users not only need to log in to the Active Directory domain but also need to enable the Windows SSO feature on their browsers. Below are the configuration instructions for both Microsoft Internet Explorer and Mozilla Firefox.

Microsoft Internet Explorer

1. From the Internet Explorer menu, select Tools – Internet Options, and then click the Security tab.
2. Click the Local intranet icon, and then click Sites.
3. Click Advanced, and then add the Web address of the host name of your Web applications –- typically the host name of HTTP server -– into the Add this website to the zone field. For example, *.enterprise.example.com.
4. Click OK to save the change and return to the main Security page.
5. Click Custom level, scroll to find User Authentication – Logon, and then select Automatic logon only in Intranet zone. Click OK to save the change and return to the main Security page.
6. On the Advanced tab, scroll to find Security, and then select Enable Integrated Windows Authentication. Click OK to save the change.
7. Restart the Web browser to apply the configuration changes.

Mozilla Firefox

Use the following steps to add the Web address of your Web application to the list of sites that are permitted to engage in SPNEGO authentication with the browser:

1. Open Firefox, and then type about:config in the location bar.
2. Type network.n into the Filter field, double-click network.negotiate-auth.trusted-uris, and then type the protocol and host name of the server that hosts your Web application. For example, http://enterprise.example.com, or https://enterprise.example.com, if you want to use HTTPS. To specify more than one server, separate them with a comma.
3. Click OK to save the change.
4. If the deployed SPNEGO solution is using the advanced Kerberos feature of Credential Delegation, double-click network.negotiate-auth.delegation-uris. This preference defines the sites for which the browser can delegate user authorization to the server. Enter a comma-delimited list of trusted domains or URLs.
5. Restart Firefox to apply the configuration change.

Conclusion

In this article we introduced the Windows SSO configurations on both WebSphere Application Server and Lotus Domino. The configurations include the common steps for Kerberos of time synchronization and SPN registration, and the platform-specific configurations owing to the different approaches that WebSphere and Lotus Domino use SPN credentials.

For WebSphere, the keytab file and krb5.conf file are used to enable JVM with Kerberos capabilities, and for Lotus Domino, the Domino server is run with the account under which the SPN is registered. Also included were some optional configurations that might be helpful to fulfill the requirements in your specific deployment. To incorporate with the Web server, we also provided the client browser configurations for successful Windows SSO.