I wanted to check the expiration date of certificates used for SQL database mirroring.
Here is how you do it.

Just open SQL Management studio and make a new query on the master DB:

select * from sys.certificates

In the results you can check the expiration date and time in the column expiry_date.

Remember to renew the certificates in time

Microsoft has released a very important update for SharePoint, the Infrastructure Update:
http://blogs.msdn.com/sharepoint/archive/2008/07/15/announcing-availability-of-infrastructure-updates.aspx

The update should be installed ASAP.

This document describes changes for Kerberos:
http://technet.microsoft.com/en-us/library/cc263449(TechNet.10).aspx

Recently I got a comment how to locate duplicate SPNs when using Windows Server 2008.

Luckily, this is very easy, because the SETSPN command from Windows Server 2008 has this functionality builtin:
http://technet2.microsoft.com/windowsserver2008/en/library/39b7428a-2b45-4640-9bd7-46833007d38d1033.mspx?mfr=true

Remove the duplicate service prinicipal name

Each service principal name (SPN) must be unique. Without unique principal names, the Kerberos client is not able to ensure that the server it is communicating with is the correct one. You must identify the duplicate SPN, and then remove it.

To perform these procedures, you must be a member of the Domain Admins group, or you must have been delegated the appropriate authority.

To identify the duplicate SPN:

1. Log on to the computer referenced in the event log message. If this computer is not running Windows Server 2008, you must download and install the Windows Server 2003 Resource Kit, which includes setspn.exe.
2. Click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
3. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
4. Type setspn -X.
5. The output of this command will show the duplicate SPNs.
6. Use the following procedure to remove one of the duplicate SPNs.

Remove an SPN

To remove an SPN:

1. Click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
3. Type setspn -D<SPN> <computer_name>, where SPN is the name of the duplicate SPN and computer_name is the name of the computer that is assigned the duplicate SPN.

Okay, we have configured our MOSS site so that the users are able to authenticate with Kerberos.
But how do we know for sure that Kerberos was used and the authentication has not fallen back to NTLM? Here is what we can do with the right tools.

At first, we should install a tool which allows us to have a look on the traffic between the browser and the server. The tool I prefer is called Fiddler, you can download it from here: http://www.fiddlertool.com/Fiddler2/version.asp.
Just install it on a client machine and start it. It works as a proxy between the browser and the client, so you should take a client that reaches the MOSS server without another proxy. Then just open your browser and then your MOSS site. Fiddler should log the HTTP packets and you should get something like that:
 
In the screenshot we can see that NTLM was used and we have to find the reason why Kerberos was not used.

Very often the reason is a very simple one: duplicate SPNs.
Here is a way to export all existing SPNs of a domain:

ldifde -f c:spn_out.txt -d “DC=test,DC=local” -l serviceprincipalname -r “(serviceprincipalname=*)” -p subtree

In my test environment the Active Directory Domain was called test.local, you have to alter the command with your domain name.

Here is the output from the command:

Here is the generated text file:

As you can see, there are a lot of SPNs, even in a very small environment. This makes troubleshooting very difficult, especially in large environments.
What can we see in the screenshot above? The problem is, that the SPNs are sorted by security principals (computers, users) and not by services. In my example I intentionally created two SPNs for my MOSS site testapp.local.

Here is the screenshot with the highlited duplicate SPNs:

As you can see, the service HTTP/testapp.local is registered two times, for the user mossservice and the user sqlservice. When a user wants to authenticate to the MOSS site with Kerberos, he cannot know for which user he has to request a Kerberos ticket and Kerberos fails.

But there is an easier way to discover duplicate SPNs. When you are troubleshooting Kerberos authentication, you know the name of the service the user wants to connect to. In my case the MOSS site has the hostheader testapp.local and the service is HTTP/testapp.local.
Microsoft provides a script to discover duplicate SPNs. You can download the source here: http://support.microsoft.com/kb/929650. Just copy the sourcecode to a text file and rename it to SPNHelper.vbs. Then you can use this script with the following command:

cscript SPNHelper.vbs /f:duplicatespn /spn:HTTP/testapp.local

(Note that the help says the command should be cscript SPNHelper.vbs /f:duplicatespn /spn:HTTP:/testapp.local [the : after the HTTP in the SPN], but his is a typo!)

The script gives us this output:

Now we can be sure that Kerberos cannot work, because we have duplicate SPNs.
We have to delete the wrong SPN:

In my example, the application pool ID of the MOSS site is testmossservice, so testsqlservice was wrong.

Now we can make another authentication test with Fiddler, but at first we should delete the previously logged session for clarity:

After we open the MOSS site another time, Fiddler states that Kerberos was used:

That’s it!

When you create a new web application on your MOSS 2007 server, you have to make a tough choice: NTLM or Kerberos.
The differences for the user are not visible, but we have to make a few settings to make Kerberos work.

The easy settings are done with the Central Admin of MOSS:

Just enable Kerberos in the Authentication Provider of the desired Web Application.

That was the easy one.

Another thing we have to do is to set a “Server Principle Name”(SPN). A SPN is needed, because the user who wants to authenticate with Kerberos needs to know the account under which the Application Pool is running (Application Pool ID). The authenticating user needs this information, because he needs to ask the Kerberos Key Distribution Center (KDC) for a ticket for this account.
Naturally, we provide this information with a directory service. You have three guesses what directory service we will use.

The tool for registering SPNs is called SETSPN and it is installed with the Support Tools.

Here is an example:

Application Pool ID:

 
The application pool ID in my example is the user MOSSSERVICE in the domain TEST.LOCAL (TEST).

URL (Hostheader) of the application:

This is what your users enter into the address bar of their browser.

So we have:

That gives us this SETSPN command:
setspn -a http/testapp.local testmossservice

That’s it.

Yes, really, it is that easy!

In my next post I will show you how to test if the authentication is made with Kerberos or falls back to NTLM.

Sobald man sein Netzwerk um Mobilität “erweitert” hat und so Pushmail mit Exchange 2003 SP2, RPC over HTTP(S) für Outlook und Outlook Web Access einsetzt, hat man sowieso mindestens einen IIS Server im Netzwerk und den Port 443 (HTTPS) von außen verfügbar gemacht.

Was liegt da näher als auch seine Dateien mobil verfügbar zu machen?

Dafür gibt es ja WebDAV.

Aber wenn schon von außen Zugriff auf interne Dateien, dann auch entsprechend abgesichert. Die Datenübertragung wird ja schon durch SSL geschützt, fehlt noch die sichere Authentifizierung, am besten mit zwei Faktoren.
Hier kommt wieder RSA SecurID zum Einsatz.
Bleibt nur das Problem, dass wir zwar eine normale Webseite mit SecurID absichern können (siehe meinen Blogcast “Absicherung von OWA mit SSL und SecurID), aber Webdav und das Feature “als Webordner öffnen” im Internet Explorer kommen mit der vorgechalteten SecurID Authentifizierungsseite nicht klar.
Hierbei können wir uns aber den Umstand zu nutze machen, das man sich nach einmaliger Authentifizierung nicht direkt neu authentifizieren muss, sondern das man ein Cookie bekommt, dass einige Zeit gültig ist.

Der Trick ist nun folgender:
Als erstes authentifizieren wir uns an einer mit SecurID abgesicherten Webseite (z. B. OWA), um dann den Webordner zu öffnen. Da das durch die erste Anmeldung erhaltene Cookie noch gültig ist, müssen wir uns nicht noch einmal authentifizieren und WebDAV bzw. der Webordner bekommen keine Probleme.

Schon kann man auch unterwegs Dateien auf seinem Server ablegen oder dringend benötigte Dateien runterladen.

Ich habe es endlich geschafft den vorerst letzten Blogcast zum Thema RSA SecurID aufzunehmen.
In diesem wird die Remoteauthentifizierung mit einem Passcode und vor allem die technische Einrichtung gezeigt.

Dieser Blogcast ist wieder in Windows Media Video und Flash verfügbar:

Windows Media Video

Flash Video 1024×768 (empfohlen)

Flash Video 900×675 (kleiner dargestellt, schlechtere Qualität)

Viel Spaß!

Gestern meldete der Heise Newsticker (http://www.heise.de/newsticker/meldung/72701) dass die Authentifizierung unter Windows Vista nicht native, also von Haus aus mit RSA Securid stattfinden kann.
So sagte Art Coviello, Chief Executive von RSA Security in einem Interview:

This meant that deploying a token-based system still required “some work”.

(Quelle)

Es bleibt also alles so wie es schon bei Windows XP ist: man muss die GINA austauschen, um sich mit RSA SecurID authentifizieren zu können.

Mein Fazit: Macht nichts, ist ja einfach zu bewerkstelligen:
http://hemker.blog.de/2006/04/27/blogcast_domanenanmeldung_mit_securid~759681

Ich habe gestern den Blogcast zum Thema Domänenanmeldung mit SecurID aufgezeichnet.
Dieser beschreibt die notwendigen Installations- und Konfigurationsschritte. Zusätzlich ist dort erklärt, wie man einen Massenimport und eine Synchronisation von Benutzern aus Active Directory in die RSA Authentifizierungsdatenbank durchführen kann.

Wichtig bei der Konfiguration ist übrigens, dass der Authentifizierungsmanager nicht auf dem Domänencontroller laufen darf. Ist dies der Fall, so läuft die Passwortintegration nicht, die Benutzer müssen also nach der Authentifizierung mit ihrem Passcode immer ihr Windows Passwort eingeben.

Hier das Windows Media Video:

Windows Media Video

Gestern habe ich den zweiten Teil des Blogcasts um OWA und SecurID fertiggestellt.
Ich habe diesen in Windows Media Video und Flash konvertiert, damit alle die Wahl zwischen den Formaten haben.
Das Flashvideo in 900×675 ist kleiner dargestellt als die Originalaufnahme, daher ist die Qualität nicht so berauschend. Wen das zu sehr stört sieht sich bitte das große Flashvideo oder das Windows Media Video an.

Flash 1024×768 – Flash 900×675

Windows Media Video

Hier nochmal die im Blogcast genannten Links für den direkten Aufruf:

Download des RSA Webagent

Aktivieren und Anpassen der Formularbasierten Authentifizierung

Kommentare immer willkommen.