To start off, do not implement ISA Server in a workgroup, unless you really, really want to. I would prefer to leave it part of the domain in most scenarios. This post is not to debate “To Join or Not to Join” the domain. ISA Server MVP Tom Shinder has written a beautiful article listing out good reasons why ISA Server SHOULD be a domain member.
Now, what if you went ahead and deployed your ISA Server in a workgroup due to technical/security (aww come on)/nagging manager reasons and had to set up LDAPS for authentication between your ISA Server and domain controller? Of course the normal Active Directory authentication will not work from the ISA Server computer because it is not a member of the domain, hence we need to use LDAP or LDAPS (Secure LDAP).
For certain features like the ISA Server 2006 FBA Change Password option to work, configuring LDAPS properly is a must.
To use LDAPS, you need to install a server certificate on the LDAP server (domain controller in this case), and the root certificate from the CA that issued the server certificate should be installed on the computer running ISA Server. Here’s an article on how to do that (yes, it applies to Microsoft CA as well).
Once you’ve done all this stuff, you can check if all is well by trying to run the LDP.exe tool from ISA Server as mentioned in the article. Pay special attention to the issues section at the end of the article.
If you still face problems, and suspect the certificates may be the problem, open Internet Explorer on the ISA Server computer, and browse to https://myldapserver.domain.local:636. If you have configured everything correctly, you should not receive any certificate errors. Of course, you will eventually get ‘Page cannot be displayed’. In addition, The following warning can be ignored:
However, if you get an error regarding a name mismatch or expiry of certificate, you need to sort these out first.
Once this works without errors, and you still face problems, run the ISA Server Best Practices Analyzer and look for any certificate related issues and resolve them.
I found this great piece of information on the TechNet website, that’s worth posting here. It’s an explaination on how domain controllers check passwords during authentication. I’ve re-written it in my own words to make it dummy-friendly (I like it that way!).
1. The client computer sends the user logon information (user account name and a crypto hash of the password) to the ‘nearest’ domain controller.
2. DC tries to verify the password. If it works, great! let the client know he’s in. If it did not work, either due to ‘wrong password’, ‘expired password’, ‘password must change on next login’, or due to ‘account lockout’, the domain controller forwards the authentication attempt to the PDC emulator. Since PDC Emulator is always notified whenever a DC changes a password, the PDC emulator will always have the latest password for any user at any given point of time. Hence, the authenticating DC passes the logon info to the PDC Emulator (just in case the authenticating DC doesn’t have latest password yet).
3.PDC emulator retries the authentication. If the PDC emulator operations master rejects the bad password, the password is definitely wrong! The PDC emulator operations master increments the badPwdCount attribute for that user object. The PDC is also the authority on the user’s password validity.
4. PDC Emulator informs the authenticating DC that the password didn’t work.
5. The authenticating domain controller also increments its copy of the badPwdCount attribute for the user object.
6. The authenticating domain controller then sends a response to the client computer that the logon attempt did not work.
As long as that user, program, or service continues to send bad passwords to the authenticating domain controller, logon attempts that failed because of an incorrect password continue to be forwarded to the PDC until the threshold value for incorrect logon attempts is reached (as per your Password Policy). When this occurs, the account is “locked out”.
So you opened ADSIEDIT and checked the LastLogon attribute for a user, expecting a decently formatted date and time – and instead – found something like this: 128271382742968750.
This is the Windows NT time format. Before you jump out of your chair, lets find out what this actually is. Believe it or not, the lastLogon attribute is stored as the number of 100-nanosecond intervals that have elapsed since the 0 hour on January 1, 1601! (Umm.. no, I don’t know why!)
So how do we convert the LastLogon value to human-years? You don’t need to pull your hair out, you can use this command:
w32tm /ntte [time in NT format] For instance, if we want to convert 128271382742968750:
To add a twist in the tale, notice that the date/time in NT Time Format is stored in GMT time. Since I am in the GMT +3:00 timezone, w32tm first listed the original value and added +3:00 to it to give me the output in my local time.
Another twist: Active Directory does NOT replicate the LastLogon attribute across domain controllers. So in order to get an accurate value, you need to obtain the LastLogon value for the same user from all your domain controllers and accept the value that is highest.
However, if you get an error regarding a name mismatch or expiry of certificate, you need to sort these out first. 
