Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

How do you do a transparent login into sharepoint - getting rid of

  Asked By: Wayne    Date: Jan 10    Category: Sharepoint    Views: 10474

We have a web site which links into Sharepoint. We are trying to pass the
username and password from the website (SQL server) transparently into
Sharepoint, thereby avoiding the NT login box. That is, once users have
logged in to the website, we don't want them to login to Sharepoint as well.
It should go straight through.

Sharepoint only works properly when you disable anonymous access to the
virtual site. Therefore, you get a login prompt when you go into Sharepoint.
This could be avoided if the site was anon. access disabled too so that
there is only one login (NT box) which produces a token. However, we have
the site and Sharepoint on separate IP's (seems to only work this way) so
any tokens created on one IP seem to be lost when you go to the new IP (is
this right?). I'm not too got on Win2K security concepts I think I'm right
in saying you can have domain account holders go directly into Sharepoint?
So providing they have a token, they ought to be able to go directly into
Sharepoint without having to login again, but try as I might I cannot get
them into the domain.
I had thought that when you logged into a domain (from boot into windows os)
you should be on the domain and able to go anywhere ('cos you are on the
domain & have a token). However, this doesn't work and Sharepoint again
prompts users for a username/password. I have tried using the API as well
but I cannot find an API that works in the same way as the basic NT login
box. I have tried the logonuser function but that didn't work.

Has anyone attempted this? Could they provide some background on their 2000



5 Answers Found

Answer #1    Answered By: Sydney Lewis     Answered On: Jan 10

wE MANAGED TO GET A transparent login  by passing the domain, login & pass
though the url. Not that secure but you can play around with it to conceal
the username / pass  in the page. We sent th data out to another page in a
I'd still like to be able to send the username and pass to an api  function
but i don't know anyone eho's done this!

Answer #2    Answered By: Ira Knox     Answered On: Jan 10

Is your Sharepoint machine member of the NT domain  where your users  are
defined ?

SPS automatically authenticate based on domain

Also what is your default security  on the workspace ?

Answer #3    Answered By: Divyesh Hurkadli     Answered On: Jan 10

Do you mean that if I log on to my remote machine as a
client within our domain, I should pass  directly through to sharepoint  when
access  it? We have tried this but SP keeps asking for another login. I can
imagine this might work  locally but what about internet users?

Our goal is have users  from the internet - with domain  accounts - pass
through to Sharepoint without logging in twice. I would therefore need to
authenticate users prior to going to sharepoint, possibly using some API
code such as logonuser? I could make the web  site deny anon.user, which
would force an NT logon but we tried this and ended up having another login

Can you elaborate on what you mean by default security  for webspace? Do you
mean the prmissions on the folder or the virtul IIS directory security? We
have basic  I think, and have tried integrated as well. What do you

Answer #4    Answered By: Darryl Nguyen     Answered On: Jan 10

I think I found a solution to your problem

2 options

To avoid a dialog box  construct the following URL


So let's say that your domain  is mydomain, username is user and password  is
pass and the FQDN is mysps.com and workspace is mywp

<http://mydomain%5cuser:pass@mysps.com/mywp> will let you in, I tested this
and it works  on an extranet

One think that you need to be aware is that IIS will not be able to digest
credentials from the Internet, it seems to me that Firewall or proxy will
not digest this but it depends on what Firewall/proxy you use.I know we had
problem with our firewall

One think for sure is that if you try to access  your sps server  from within
the domain you should NOT get a dialog box.

In my configuration, if I access the same server internally with the
internal DNS name, I do NOT get a dialog box but as soon as I access it with
a different name, i.e. (with outside IP address) I will have a dialog box.

To achieve the scenario, you could build a page with VBScript client that
will capture the credentials and pass  them to the URL construct I gave you
above. But be careful as password will be sent in clear text unless you use

The other option is set in your local Internet Explorer, I assume you use
Internet Explorer. There is a security  setup that prevents sending local
credentials to the server when outside of the local subnet. (i.e. Intranet

To change this, go to Internet Options in IE, click on the Security Tab,
Click on Local Intranet, Sites, Advanced and enter the name of your site,
i.e. in my case http://mysp.com <http://mysp.com> . This will force IE to
send credentials for this site.

The reason for this is a security setting in IE, if you go to Custome Level,
the last option will be User Authentication, and the default setting is
Automatic logon only in Intranet sone, you could change to Automatic logon
with current credentials but this could cause some side effect to have the
credentials sent to every server you go out to.

Answer #5    Answered By: Tom Pruitt     Answered On: Jan 10

Your solutions both worked. We've decided to go with the first one as it is
obviously more convenient. The only problem is we are passing the username
and password  in the URL, which is a security  issue. However, I'm sure we can
explore ways to minimise this.

We can't use http agent or other environment variables with SSL because the
username and password are session variables in the asp page, which are
produced after successful login  to the website. I suppose we could simply
capture the login details from the windows  initial login box  (i.e. from
start-up) and pass  those through to the website  and to Sharepoint. These
would be encrypted if we take off basic  authentication<?> However, the
implication of this is that only domain  account holders can access  the web
site which may not be desirable as not all users  will be sharepoint  users.

Perhaps later I will try to get the API call to work  so we can generate
token for authenticated users.