How to install the ADKeepAlive service
This document explains how to install the ADKeepAlive service. A downloadable ZIP file is included in the installation steps, and Microsoft details about an initial delay in the SSL session are also provided.
Installation
Download the file: ADKeepAliveService_withMultipleUsers.zip.
This ZIP file contains 4 files:
ADKeepAlive.aspx
ADKeepAlive.aspx.cs
ADKeepAliveService.exe
ADKeepAliveService.exe.config
Copy the
ADKeepAlive.aspx
andADKeepAlive.aspx.cs
files on the SecureAuth realm(s) on which you want the service to run.For example,
D:\SecureAuth\SecureAuth1
Copy the
ADKeepAliveService.exe
andADKeepAliveService.exe.config
files to the folderD:\MFCApp_bin\ADKeepAlive
.If this folder does not exist, create it.
To install the new Windows KeepAlive Service, run the following command as shown next.
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe" "D:\MFCApp_bin\ADKeepAlive\ADKeepAliveService.exe"
Open the
ADKeepAliveSErvice.exe.config
file in Notepad and modify the following lines.UserIDs - If you need to use the keep alive service on several domains, you must assign a service account to the respective URL
Use a semi-colon to separate each account
If using only one realm or one AD domain, remove the semi-colon and second UserID
Do not delete the </value> at the end of that line
URLs - This service can support multiple realms which are using multiple LDAP / AD domain/Servers
Use a semi-colon to separate each realm
If using only one realm or one AD domain, remove the semi-colon and second URL
Do not delete the </value> at the end of that line
Passwords are optional and adhere to the same methods described for UserIDs and URLs
ADKeepAliveService.exe.config example
<?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="ADKeepAliveService.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" /> <section name="ADKeepAliveService.Settings1" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" /> </sectionGroup> </configSections> <userSettings> <ADKeepAliveService.Properties.Settings> <setting name="UserID" serializeAs="String"> <value>SVCACCTn;SVCACCTn+1</value> </setting> <setting name="URL" serializeAs="String"> <value>https://mysecureauth.fqdn.com/<Secureauthn>/adkeepalive.aspx;https://localhost/<Secureauthn+1>/adkeepalive.aspx</value> </setting> <setting name="Interval" serializeAs="String"> <value>30</value> </setting> <setting name="WriteLog" serializeAs="String"> <value>Y</value> </setting> <setting name="Password" serializeAs="String"> <value /> </setting> </ADKeepAliveService.Properties.Settings> </userSettings> </configuration>
Start the new AD Keep Alive Service.
You will see a text log file created in the folder. By default,
WriteLog
is set toY
. This setting logs the results by hitting the URL (successfully or unsuccessfully).A successful GetUser function call returns
Good GetUser
An unsuccessful GetUser function call returns
Bad GetUser
(needs attention)
It may take 30-60 seconds for the log file to populate the first
Good GetUser
results.A sample of the output log appears next.
ADKeepAlive Service Started - 4/30/2012 4:34:00 PM https://secureauthqa.gosecureauth.com/SecureAuth20/adkeepalive.aspx?uid=user07&pw= Good GetUser - 4/30/2012 4:34:33 PM - 4/30/2012 4:34:33 PM Good GetUser - 4/30/2012 4:35:00 PM - 4/30/2012 4:35:00 PM
If you see consistent
Good GetUser
entries inD:\MFCApp_bin\ADKeepAlive\log.txt
do the following:In the
ADKeepAliveService.exe.config
file, change theWriteLog=N
to prevent the log file from becoming too large.Save the
ADKeepAliveService.exe.config
file and restart the service.
Microsoft details on the Initial Delay in an SSL session
See the article at this link for information about the initial delay in an SSL session: http://blogs.technet.com/b/ad/archive/2007/06/19/a-new-twist-on-initial-delay-in-ssl-session-setup.aspx
The first part of the article explains how a 20-second delay exists due to SSL and certificate permissions issues.
The second part of the article describes how a lack of an SRV record in the DNS can throw off LDAP lookups for 20 seconds or more in the IIS Server's attempts to call a server it can't find.
To address this concern, a test can be conducted by performing an nslookup
for an SRV record (see http://support.microsoft.com/kb/816587) to ensure SRV records exist for the servers being called.
If the nslookup
returns empty, a DNS issue may be the cause.