ISA Server Authentication issues in a mixed Windows/Macintosh environmentFrom: Ken Stigler (Ken@STIGLAND.COM)
- Previous message: Jeff Kratka: "Re: Alert: Microsoft Security Bulletin - MS02-016"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 11 Apr 2002 20:08:15 -0400 From: Ken Stigler <Ken@STIGLAND.COM> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Not sure if this has been covered here yet or not but...
I have a client - a local public school system - with a mixed
Windows/Macintosh environment. Basically, the kids start school on
Macs, and sometime switch over to a pure Windows environment by the time
The environment is a single NT4 domain, 1 PDC, 1 BDC, several
application servers, a web server, an Exchange 5.5 server. Some
machines are Windows 2000, most are NT4.
They had a Proxy server/Checkpoint Firewall solution to the internet and
wanted to switch over to an integrated ISA solution for many reasons.
Due to District policies, students are required to have their parents
agree to allow them to have internet access. As a result,
authentication at the ISA server takes place in order to allow a student
access. Basic authentication is the order of business, since the lower
grades have a hard enough time remembering passwords, let alone domain
Here is the issue. The cutover went well. After much testing, every
thing seemed in order. Applications worked, web servers worked,
The testing took place over Spring Break. The users who were onsite
that day had absolutely no problems accessing the internet,
authenticating, etc.... Life was good....
Then school started!
Almost immediately, there were problems with authentication of students.
not all, just a lot. At first it seemed to be entire schools down, but
upon inspection, it was individual users, not locations or machines.
The bizarre part was the fact that if user A was able to access the
internet, they could access the internet anywhere, from any building,
machine, etc. If user B is unable to access the internet, they could
never access the internet - anywhere.
The fix..... Ready? If User B had their password reset ( and by reset,
I mean reset to the EXACT SAME password) they user was then able to
access the internet, consistently.
After testing, it was discovered that the problem users were users that
had changed their passwords on a Macintosh were unable to authenticate
against the ISA server.
Microsoft sent a debug version of netlogon.dll for testing. When a user
logged into a machine, they had a 0x0 returned from the PDC, basically
an all clear. When they tried to authenticate against the ISA for
internet access, they received a 0x0000064C (I think that was it)
basically a "bad password" response.
To verify and test, I took several users from an elementary school (all
Macintosh users, all with failed access to the internet) I reset their
passwords via User Manager and successfully authenticated each of them
against the ISA for internet access from both a Windows machine and a
Next, I changed their passwords via the Macintosh client. I was able to
successfully change the password, log into the domain from any windows
machine, access network resources from a Macintosh, but was UNABLE to
authenticate against ISA for internet access. I change their password
on a windows machine either via user manager, the control panel, or a
ctrl-alt-del screen and they can once again authenticate and access the
So, it seems that the authentication engine that ISA uses to communicate
with the domain for authentication has some issues. Not sure if it is
a parsing or hashing issue, but there is an issue.
I guess I find it odd that the ISA server would use a new or different
authentication engine than any previous MS product.
This issue DOES NOT seem to affect a Macintosh OS X client, however...
OH, BTW, there are absolutely no other problems with authentication in
We thought a corrupt SAM was to blame, so a new machine was built as a
BDC, synchronized and promoted to a PDC. The original PDC (now a BDC)
had its net logon services shut down to take it out of the picture....
Still no difference. We were hoping the new database replicated to the
new DC would take care of any inconsistencies or corruption....
Due to budget constraints, the school district does not have the
hardware to implement a test Windows 2000 AD environment at this time.
This possibility was discussed, with the assumption that the SAM
database from the NT domain would be restructured for Windows 2000 and
possibly fix the problems, but with no $$, there is no test!
Any thoughts or suggestions would be appreciated...