Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds


  Asked By: Sandy    Date: Oct 08    Category: Sharepoint    Views: 2165

I have an issue with Authentication on the sharepoint server. After I authenticate to the server, I continue to get prompted for authentication everytime I open a document. How do I stop this? I have played with session timeouts, asp timeouts and nothing seems to work.



22 Answers Found

Answer #1    Answered By: Darrell Peters     Answered On: Oct 08

If you are using Sharepoint from a workstation that is not in the domain of the server, you will be prompted  for authentication. The problem is not a problem with Sharepoint but with the target application of the document. Internet Explorer has no way to pass the credentials to the target application, i.e. Microsoft Word for instance. Therefore every time you open  a document  (a word document for instance), word need to authenticate  to the web server  and you are being prompted to logon. Unfortunately the only altertnative is to use Windows Challenge/Response but this will require that the workstation be in the same domain or forest of the web server

Answer #2    Answered By: Lester Casey     Answered On: Oct 08

That would be great if it was consistent at doing this, but it is not. I worked for weeks on this server  never having to authenticate  twice. Others that I worked with had the problem, but I never experienced it. Now I am experiencing it and it is still not consistent. Sometimes I have to re-authenticate, sometimes I don’t.

Answer #3    Answered By: Rudy Francis     Answered On: Oct 08

Just to confirm the client is in the same domain as the server?

Answer #4    Answered By: James Miller     Answered On: Oct 08

Actually, it is not in the same domain. The answer that you gave earlier is acceptable to me, but the problem I have with it is the inconsistency. I would prefer not to have my clients re-authenticate, and if there is anyway to do that…I am open  to it. The clients that will be accessing this system will be in many different forests…some trusted, some not.

I am open to any ideas that you may have.

Answer #5    Answered By: Collin Griffith     Answered On: Oct 08

Well it may be a IE problem, when you access the portal what does IE say in the bottom right for the zone.

Internet Explorer will only pass credentials to the server  if IE detects the server as “Local Intranet” Zone.

In order to force a server to be in the Intranet Zone, you need to go to “Tools, Internet Options, Security, Local Intranet, Click on Sites, Click on Advanced and enter the URL of your server.

This will force IE to recognize your server and push credentials

Answer #6    Answered By: Scott Nelson     Answered On: Oct 08

We have progress. I put the sites into the intranet zone and modified the intranet zone to pass credentials across domains. This works…except now I never get prompted  for authentication  at all! I am trying to clear any password cache / temp files out of my machine to ensure that I get prompted one each session. I am trying to develop some instructions to send out to the user community on how to configure their system to access the sharepoint.

Answer #7    Answered By: Blake Marshall     Answered On: Oct 08

Not sure if MS Office apps (Word, Excels, etc) has any thing to do with
authentication directly in this manner.

I experienced similar behavior and fixed it by editing . . . .\Microsoft
Shared\Web Server Extensions\60\Template\Xml\HtmlTransInfo.xml to set ProgId
to empty (i.e., ProgId = "").

I remember seeing a MS advise somewhere, acknowledging this as a bug in
Sharepoint and giving out above edit tip to fix it.

If the cause is same then it should fix your problem in 10 mins.

Answer #8    Answered By: Dwayne Jensen     Answered On: Oct 08

I was hoping to start a discussion on my situation and sharepoint  configuration stated below

SharePoint is configured on one domain
Our users on on another domain....
Only Port 80 is open  between domains... no other port is open
The active directories are not "trusted" between domains and not an option to have them trusted
Therefore basic authentication  is implemented so users can log in, anonymous access isn't an option because we want to use sharepoints full functionality,
Due to this scenario, every time a user either browses to SharePoint site or opens a document  in an office product, a login dialog appears. This is not something our users want to have happen.

Ultimate solution would be to somehow mimic IWA between the 2 domains, but we would settle for only one login and not the subsequent logins every time we open an office product.

One solution I thought about was creating and ISAPI Filter that would "authenticate" users before the request made it to the SharePoint ISAPI Filter. Does anyone think or know if this would work? ISAPI filter's can be created for that purpose so I am thinking it might work, but I don't want to be a bunch of time and effort into it if people know different.

Answer #9    Answered By: Jose Baker     Answered On: Oct 08

I doubt it would help, as every process needs to be authenticated. Because Office is another process, there will be a login prompt. The only way to mitigate this is to keep word open, by just closing the document, and not word itself… keeping outlook open  sometimes helps.

Answer #10    Answered By: Cornelius Guerrero     Answered On: Oct 08

I keep on reading that word or office for
that matter does its own authentication... but i don't see how if
all authentication  is controlled through IIS. It seems to me that
word is using the "url" that is served through IIS to authenticate.
The document  is housed in the database with the only access through
a url... Therefore, how can it be using any other authentication
besides through IIS.

Can anyone clarify if the above statement is wrong?

Answer #11    Answered By: Roderick Wolfe     Answered On: Oct 08

A few things …

1) You can use ISAPI to manage authentication  before sharepoint  gets the request – we do that currently.

2) You can write a persisted cookie with an encrypted session  password. Word will submit the cookie when making the request to SharePoint. So if you have an encrypted cookie and that gets converted to an HTTP-based auth before the SPSFLTR (SharePoint ISAPI filter) sees it, you should be fine.

3) Having any kind of password on the client system – even encrypted – is a security risk. We have a session password model where passwords are reset for each session to address this issue.

4) Fundamentally, the issue  with Office applications, IE, and authentication is that the password is stored by IE in process. Word, Outlook, etc. don’t have access to this password to resubmit it.

Answer #12    Answered By: Johnny Cruz     Answered On: Oct 08

I knew there had to be a way around this problem

I have more questions with regards to this issue. I don't know if you would be up for answering them through here or offline or at all, but I will throw them out here.

1) What type of authentication  do you set aynonomous? or intergrated?
2) Does IIS process the filters first? Or does it authenticate  first?
3) Any good articles or hints on how to write this ISAPI filter?

Answer #13    Answered By: Norman Santos     Answered On: Oct 08

1) We set authentication  to BASIC. It simplifies the encoding of the password into the request.

2) It depends upon which methods you use. You can process the request before IIS authenticates it.

3) There aren’t any good resources for writing one although there are a few of us who have had to do it. It requires C++ so it’s a high cost to solve the problem.

Answer #14    Answered By: Walter Stone     Answered On: Oct 08

Yes, I realize that its going to take c++ to write it... I used to develop COM objects in c++ so it won't be too much of a stretch, plus it will let me do some real development again.

I was thinking of implementing something a little different then basic authentication. Any reasons why this won't work  or be a security concern?

1)On the request, grab the username from the header and have that username map to some custom db that will have the login information for my Active Directory.
2) implement SSL and certificates (this will let me know that the client is who they say they are) so a password from client to server  is not needed
3) implement either aynonomous or IWA in IIS so no prompt comes up... (should work cause by the time IIS gets it they should be authenticated by my custom work around)

what do you think?

Answer #15    Answered By: Jamar Yates     Answered On: Oct 08

I want to know whether we can simulate forms authentication  by
actually using windows authentication.
Let me explain, I want to know whether we can provide user with a login screen
where he will enter his credentials and then redirect to home page?

Answer #16    Answered By: Aaron Lopez     Answered On: Oct 08
Answer #17    Answered By: Terry Webb     Answered On: Oct 08

There is a FBA provider that uses AD as a backend as one of the examples
in MOSS 2007.

Answer #18    Answered By: Earl Craig     Answered On: Oct 08

I would like to know how we can implement in MOSS 2007.

Answer #19    Answered By: Ross Watkins     Answered On: Oct 08
Answer #20    Answered By: Jeremiah Wallace     Answered On: Oct 08

I followed the steps. I could get the login form, but if I enter the
user credentials i got an error "Unable to establish secure connection with
Do we need to increase the trust level of the membership provider dll? Does this
solve the issue?

Answer #21    Answered By: Tony Freeman     Answered On: Oct 08

Does your LDAP server  require authentication? Are you certain the MOSS
server has network access to the LDAP server and the configuration
settings are correct?

Answer #22    Answered By: Danny Shaw     Answered On: Oct 08

Does your Web Application pool or the connection account specified in the
Membership Provider have Read Access to the AD domain you are trying to connect
to? Is this an external server  in a DMZ trying to connect to an internal DC?

Didn't find what you were looking for? Find more on Authentication Or get search suggestion and latest updates.