we have used NT accounts to travel between the web site and
sps in a similar setup to your own. nt seems to want to aunthenticate at
every turn when the token is created per session. However, when a user logs
on to the network (i.e. from bootup) the user is allowed to transparently
move between site and sps. the crucial factor in permitting this
transparency was the browser  settings themselves - within the security tab.
Setting these to 'use previous username/password' and adding the FQDN to the
list of intranet sites was the main key  to success. I do not know if this
will be any help  to you but we spent ages on it - even writing logonuser
api - so if you want help, give me more info. & i'll try to be of some
assistance!

I will try this. Does this forward  the credentials
from IIS to SPS and to SQL 2000. I mean how were you accessing the database.
In our case the web parts access the asp pages through XML http which in
turn uses ADO objects to access the database.

One more question....
if you have used the setspn.exe utility how do you add a service principal
to the KDC.

the SQL 2000 help  syntax

setspn -A MSSQLSvc/Host:port serviceaccount

did not work for me.
from machineA I'm authenticating to machienB using win2K and running the
KDC. SQL server  is running on macnineB. Both are the machines are in the
same domain. I'm using Windows authentication  for logging into a database
through Query Analyzer but I still have no service tickets showing up in my
machineA cache ??? Am I missing some thing here...

You could inspect the http agent to retrive the NT logged  on user and then
use asp to get records. Would this work?
SPS users  NT model security, so provided you generate a token (i.e. log on
to a network domain) you will not get authentication  promots. I think we
found that the browser  setting in IE - Use current username password-
disabled browser authentication promoting, provided the user was in the
domain. I see you are using code in the portal  itself, whereas we went from
an independent web site on another IP.

I'm not sure what you mean w.r.t your last line - maybe someone else has
some ideas?

Do I understand you correctly? You are using ASP in a separate web site to
query SPS? And you are passing the credentials of the original caller to
SPS? That is what I am trying to do. It seems SPS is defaulting permissions
to the "Everyone" group. Users with special access permissions are not
seeing their docs. However, they do see their docs if they use the dashboard
site directly. Will your suggestion work in my case? Or am I
misunderstanding your application?

We are indeed using ASP in a separate web site and then have a HTTP link to
our SPS IP. Originally, we had a database  login system and then passed the
user/pass through the url (which was hidden in a frameset). Now, the problem
here is that you are not logging on to the network but merely authenticating
that user at that point. Thus, at the next security barrier (SPS document
view for example) authentication  will be required again. What you really
need to do is actually log that user into the domain  to prevent further
authentication prompts. I think this was your original problem? I apologise
if I have misunderstood...

Solutions - from our experience you will need to set your browser  setting to
'use windows logon' and either log the user into the domain programmatically
using API calls to Logonuser OR more simply, advise clients to log on to the
required domain at windows/startup. You can set up a trusted domain as well.
The problem is really to do with the browser - I think - and how it handles
the authentication. If you then turn off 'allow anaon. access' to your
website and access db records using the HTTP_AGENT_username object (rather
than having a form that users  fill in) you can have a full NT system, which
is secure and allows transparency between web sites and sps.

Now, if you are calling SPS objects and then dumping them back to SPS -this
is more tricky and requires that you set the 'prompt for authentication'
flag off in your code (otherwise it hangs). You have to also set the default
user rights to a higher level ( i thniks so anyway) that has the reqd.
permissions on the server.

If this is your problem & you still have problems after this post, I'll have
a look - can't remember exactly what settings we used at this point in time.

This sounds exactly like my problem! I'll give it a go. Thanks!