Pb d'accès OWA

Fabienne wrote:

Bonjour,

J'ai un 2003 serveur avec Exchange 2003 SP1 j'ai un pb d'accès en OWA
quand je me connecte http://monserveur/exchange j'ai tout le temps un
fenetre me demandant un nom d'utilisateur et un mot de passe, quoique
l'on mettre utilisateur, administreur aucun accès.

quelqu'un a une idée ?
merci à tous

Quelques début de pistes:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;175891
le même en français (si l'on peut dire au vu de la traduction)
http://support.microsoft.com/default.aspx?scid=kb;fr-fr;175891

http://support.microsoft.com/default.aspx?scid=kb;en-us;300656
le même en français (si l'on peut dire au vu de la traduction)
http://support.microsoft.com/default.aspx?scid=kb;fr-fr;300656


Sinon à cette adresse
http://www.google.fr/search?qÊche:y4n2IBUb3yIJ:searchexchange.techtarget.com/tip/1,289483,sid43_gci1025691,00.html+owa+anonymous&hl=fr&lr=&strip=1
Outlook Web Access is highly dependent on Internet Information Server.
An improperly configured IIS server can cause OWA to malfunction for
some or all of your remote users. In this article, I explain which
symptoms point to potential IIS configuration issues and how to resolve
them.

The symptoms

Obviously, not every OWA problem is going to be IIS-related. So the
first step in the OWA troubleshooting process is to recognize the
symptoms that frequently point to an IIS-related issue.

IIS is almost always to blame if users are unable to change passwords
through OWA (either when they log in or from the options page after
login). IIS is also typically to blame if users cannot access the OWA
login screen. Of course, failure to access the login screen can also be
caused by a malfunctioning Internet connection or an incorrectly typed
URL. Finally, if users attempt to access OWA and receive a VBScript
Runtime Error, a Directory Listing Denied error, or an HTTP 500 Internal
Server Error, then IIS is almost always at the root of the problem.

Verify that the default Web site is properly configured

The first step in finding a resolution is verifying that the OWA
server's default Web site is configured correctly:


Open the Internet Information Services Manager tool.

Navigate through the console tree to Internet Information Services ->
your server -> Web Sites -> Default Web Site.

Right click on the Default Web site and select Properties.

Click on the Home Directory tab.

Make sure that the Remove button isn't grayed out. If it is, then it
means that the default application associated with the Web site has not
been established. If this is the case, then click the Create button to
create the default application.

Now, switch to Properties -> Directory Security tab.

Locate the tab's Authentication and Access Control section and click the
Edit button. This will cause Windows to display the Authentication
Methods dialog box.

Verify that the Enable Anonymous Access and the Integrated Windows
Authentication checkboxes are selected. (If you are using IIS 4.0, then
the Integrated Windows Authentication check box doesn't exist. You will
have to use the Windows NT Challenge / Response checkbox instead.)

While you are at it, verify that the appropriate user account has been
assigned to the Enable Anonymous Access section. Under normal
circumstances, the account will be IUSR_servername.
Configure the Exchange virtual folder

If the Default Web site seems to be configured properly, then your next
step in troubleshooting OWA is making sure the Exchange virtual folder
is set up properly:


Return to the main Internet Information Services Manager screen and
expand the Default Web Site container.

Locate a folder named Exchange beneath the Default Web Site.

Right click on the Exchange folder and select Properties -> Virtual
Directory -> Application Settings.

Verify that a Remove button exists. If it doesn't, then you will need to
click the Create button to create an application named Exchange.

Now, select the Directory Security tab and click the Edit button found
in the Authentication and Access Control section.

Make sure that Anonymous Access and Integrated Windows Authentication
are both selected.

Finally, select the Documents tab and verify that the Enable Default
Content Page checkbox is selected and that LOGON.ASP is the top document
on the list.
If LOGON.ASP isn't the top document, then scroll through the document
list to see if LOGON.ASP exists. If it does exist, select it and then
repeatedly click the Move Up button to move the document to the top of
the list. If LOGON.ASP doesn't exist, use the Add button to add it and
then use the Move Up button to move the LOGON.ASP file to the top of the
list.

Troubleshoot password change problems

If you have followed the steps that I have outlined so far, then your
users should be able to access the OWA login screen. It is still
possible that users may not be able to change passwords through OWA
though. The number one cause of this problem is a missing Iisadmpwd
folder. IIS 5.0 and 6.0 do not create this folder by default. It's up to
the administrator to manually create the folder:


Open the Internet Information Services Manager console and navigate
through the console tree to the Default Web Site.

Expand the Default Web Site and look for the presence of a folder named
Iisadmpwd. If the folder doesn't exist, right click on the Default Web
Site and select the New -> Virtual Directory. Windows will open the
Virtual Directory Creation Wizard.

Click Next to bypass the Wizard's Welcome screen.

You will be prompted to enter the virtual directory's alias. Type
Iisadmpwd and click Next.

Now enter the path that corresponds to the virtual directory. The path
should be WINNTSYSTEM32INETSRVIISADMPWD (where WINNT is the path to
your Windows directory).

Click Next.

You will now be asked for the access permissions for the virtual
directory. Make sure that Execute is selected and click Next, followed
by Finish.

The last step in this process is to check to make sure that the virtual
directory that you have just created is set to allow anonymous access
and Integrated Windows Authentication. The procedure for doing so is
exactly the same as what you used to check the permissions on the
Exchange virtual directory.
Check your security policy

The final portion of the OWA troubleshooting procedure involves making
sure that your security policy does not prohibit password changes:


Select the Local Security Policy command from your OWA server's
Administrative Tools menu.

When the Local Security Settings console opens, navigate through the
console tree to Local Policies -> User Rights Assignment.

Double click on the Log on Locally option in the details pane to reveal
the Log on Locally properties sheet.

Verify that Log on Locally permissions are assigned to the
IUSR_servername and to the IWAM_servername accounts. While you are at
it, make sure that both the Local Policy Setting and Effective Policy
Setting options are selected.

Now verify that the IUSR_servername and the IWAM_servername accounts
also have Log on As Batch Job and Access This Computer From The Network
permissions. After doing so, OWA users should have no problems changing
passwords.