Hi Nello,
You're right about the individual users, because these machines are only
connected via a Workgroup. However, one important point to note is that
the new web server was Win2k Server, so maybe that was causing some
confusion between domain and workgroup users. I am almost certain that
these two users wouldn't have the same password, even after I changed
the password on the web server - 'cos I don't know what the password
would have been on the database server.
I think I failed to indicate the exact problem with regard to the
login. Getting IIS to run the CGI apps itself, only one managed to
start and connected to the database - any subsequent CGI apps started by
IIS failed to connect to the database. However, logging in as
Administrator, all CGI apps were run manually, and they connected to the
database fine. Even if I ran one app manually as Administrator, IIS
would still only be able to run one app itself that would successfully
connect to the database.
So, I still don't understand why changing the user's password and the
associated password for the Anonymous user in IIS made it work. I can
only assume that it has forced Win2k or IIS to do something different,
given that I had to disable the "let IIS manage the Anonymous password"
setting.
Regards,
Bevan
Nello Sestini wrote:
>
> > I manually set the
> > password for the IUSER_xxx user and then modified the web server
> > Anonymous account with the new password.
> >
> > I then logged in as IUSR_xxx (now knowing the password) and tried
> > running the CGI applications manually - they worked fine. Then, just
> > out of curiosity, I stopped the applications and got IIS to start them
> > itself by using the web interface - it worked! I was amazed!
> >
> > So, I tried a few more tests and they all worked, with IIS starting the
> > CGI applications.
>
> glad to hear you won't need to sacrifice your weekend <g>
>
> > I don't really know what was done differently, apart from changing the
> > password on the anonymous user account, but it's all working now.
>
> I have a guess about what was going on - I'll mention it because it
> is related to something about NT I've never understood.
>
> Probably IUSR_xxx on the webserver and IUSR_xxx on the db host were
> two distinct local users (as opposed to "the same" domain user).
>
> So it was possible for them to have different passwords. I suspect
> that they DID have different passwords. So IIS could impersonate
> IUSR_xxx locally just fine, but couldn't authenticate to the remote
> host because the password wasn't the same. Changing the password
> in both places fixed that problem which explains why the CGI apps
> run ok after that.
>
> The weird part is how the "priming" logon as administrator fixed
> it originally. I think it may be because NT (and presumably Win2K
> aka NT5) only allows one set of credentials to be used to "connect"
> to a remote host. So once you are connected, you are stuck with
> those credentials - you can't open up a 2nd connection with different
> credentials. So once the connection to the DB host was established
> as administrator that connection ended up getting used subsequently.
>
> This is an annoying behaviour in NT - for example if you normally
> long on as a "regular" user and have drive mappings, you can't
> temporarily map a drive to an admin share on a machine hosting
> one of your mapped drives using a different user/pass than the
> one you used for your other mappings. You weren't using drive
> mappings - but I suspect other shared resources (like named pipes)
> are subject to these same strange rules.
>
> If I'm wrong about this and there IS a way to do that I'd love
> to hear how.
>
> -ns
>
> ---------------------------------------------------------------------------
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> To UnSub, send email to: [EMAIL PROTECTED]
> with body of "unsubscribe delphi"
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
