OWA problem for one user

[Neko-]

Having an issue with one specific user having access problems to OWA.
Using an Exchange 2003 (on Windows 2003) configuration in a frontend/
backend configuration. Said user has been able to use the client
previously, but suddenly is unable to. Logging in through the Outlook
application on the desktop itself works without any problems.

* Verified permissions in ADUC, switched them off, applied, and
switched them back on, and applied. No change in behaviour.
* Added the domain before the username (i.e. domain\user) as a
loginname. No change in behaviour.
* Reset the password of the user to his own password. No change in
behaviour. (Caps aren’t being used either).
* Restarted the frontend server. No change in behaviour.

Logging in as a different user works fine (with or without the domain
added), it’s just one user having problems. I have found no records
of problems in the security eventlogs of the server, not on the front-
end OWA server, nor the backend Exchange server, nor the backend
Domain Controllers. No master/child domain configuration is active,
it’s all one domain. Issue is not limited to one computer (issue
occurs on multiple computers) and is not limited to IE7 being used,
since FireFox 3 exhibits the same behaviour: User1 can log in, and
user2 gets a notice. I therefore rule out cookies, certificates, SSL
and possible caching problems.

The user can login multiple times but appearantly isn’t authenticated.
Normally an account should lock after a few wrong passwords. In the
users case this does not happen. The screen drops back to the
loginscreen almost immidiatly. The error itself (translated from
dutch): You cannot be logged in by Outlook Web Access. Check if domain
\username and the password are correct, and try again.

Looked at http://forums.whirlpool.net.au/forum-replies-archive.cfm/553775.html,
http://searchexchange.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid43_gci1191152,00.html.

Ran through the W3SVC1 log, located this:

2008-06-25 06:51:41 W3SVC1 10.0.0.1 POST /exchweb/bin/auth/owaauth.dll
- 443 - 192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT
+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET
+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 302 0 0
2008-06-25 06:51:41 W3SVC1 10.0.0.1 GET /exchange/ - 443 user1
192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR
+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 401 1 1329
2008-06-25 06:51:41 W3SVC1 10.0.0.1 GET /exchweb/bin/auth/owalogon.asp
url=https://webmail.domain.nl/exchange/&reason=2 443 - 192.168.0.2
Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/4.0+
(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR+2.0.50727;+.NET
+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR+3.0.04506.648) 200 0 0
2008-06-25 06:52:02 W3SVC1 10.0.0.1 POST /exchweb/bin/auth/owaauth.dll
- 443 - 192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT
+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET
+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 302 0 0
2008-06-25 06:52:02 W3SVC1 10.0.0.1 GET /exchange/ - 443 user2
192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR
+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 200 0 0

The ‘reason=2’ seems to be the cause of the issue. Found the
following:

‘if the credentials are not correct, OWA will redirect back to exchweb/
bin/auth/owalogon.asp&reason=2, it will then display the message "You
could not be logged on to OWA".’

So it seems that for this one user, the OWA server doesn’t
authenticate, even if it does do this for a different user. Even if
the password has been reset, and is proven (through using the desktop
application of Outlook) to be correct.

Unfortunatly no recommended solutions. I’m almost considering possibly
removing the user completely, recreating him after a sync-period, and
reattaching the Exchange mailbox to his account. Either that, or
export the mailbox, remove the user, purge everything, and then
recreate the account and re-import the e-mail.

Anyone have any thoughts on this matter?

[Lee Derbyshire [MVP]]

When this affects one user, it usually means that they don't have an SMTP
address in the same domain as everyone else.

Lee.
--
_______________________________________

Outlook Web Access for PDA, OWA For WAP:
www.leederbyshire.com
________________________________________

"Neko-" <[e-mail]> wrote in message news:36181ba0-679e-4ceb-9b82-***@m44g2000hsc.googlegroups.com...
Having an issue with one specific user having access problems to OWA.
Using an Exchange 2003 (on Windows 2003) configuration in a frontend/
backend configuration. Said user has been able to use the client
previously, but suddenly is unable to. Logging in through the Outlook
application on the desktop itself works without any problems.

* Verified permissions in ADUC, switched them off, applied, and
switched them back on, and applied. No change in behaviour.
* Added the domain before the username (i.e. domain\user) as a
loginname. No change in behaviour.
* Reset the password of the user to his own password. No change in
behaviour. (Caps aren’t being used either).
* Restarted the frontend server. No change in behaviour.

Logging in as a different user works fine (with or without the domain
added), it’s just one user having problems. I have found no records
of problems in the security eventlogs of the server, not on the front-
end OWA server, nor the backend Exchange server, nor the backend
Domain Controllers. No master/child domain configuration is active,
it’s all one domain. Issue is not limited to one computer (issue
occurs on multiple computers) and is not limited to IE7 being used,
since FireFox 3 exhibits the same behaviour: User1 can log in, and
user2 gets a notice. I therefore rule out cookies, certificates, SSL
and possible caching problems.

The user can login multiple times but appearantly isn’t authenticated.
Normally an account should lock after a few wrong passwords. In the
users case this does not happen. The screen drops back to the
loginscreen almost immidiatly. The error itself (translated from
dutch): You cannot be logged in by Outlook Web Access. Check if domain
\username and the password are correct, and try again.

Looked at
http://forums.whirlpool.net.au/forum-replies-archive.cfm/553775.html,
http://searchexchange.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid43_gci1191152,00.html.

Ran through the W3SVC1 log, located this:

2008-06-25 06:51:41 W3SVC1 10.0.0.1 POST /exchweb/bin/auth/owaauth.dll
- 443 - 192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT
+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET
+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 302 0 0
2008-06-25 06:51:41 W3SVC1 10.0.0.1 GET /exchange/ - 443 user1
192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR
+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 401 1 1329
2008-06-25 06:51:41 W3SVC1 10.0.0.1 GET /exchweb/bin/auth/owalogon.asp
url=https://webmail.domain.nl/exchange/&reason=2 443 - 192.168.0.2
Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/4.0+
(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR+2.0.50727;+.NET
+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR+3.0.04506.648) 200 0 0
2008-06-25 06:52:02 W3SVC1 10.0.0.1 POST /exchweb/bin/auth/owaauth.dll
- 443 - 192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT
+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET
+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 302 0 0
2008-06-25 06:52:02 W3SVC1 10.0.0.1 GET /exchange/ - 443 user2
192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR
+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 200 0 0

The ‘reason=2’ seems to be the cause of the issue. Found the
following:

‘if the credentials are not correct, OWA will redirect back to exchweb/
bin/auth/owalogon.asp&reason=2, it will then display the message "You
could not be logged on to OWA".’

So it seems that for this one user, the OWA server doesn’t
authenticate, even if it does do this for a different user. Even if
the password has been reset, and is proven (through using the desktop
application of Outlook) to be correct.

Unfortunatly no recommended solutions. I’m almost considering possibly
removing the user completely, recreating him after a sync-period, and
reattaching the Exchange mailbox to his account. Either that, or
export the mailbox, remove the user, purge everything, and then
recreate the account and re-import the e-mail.

Anyone have any thoughts on this matter?

[Neko-]

I checked that too... The user has just one SMTP address, and it is in
the same domain as the rest of the users. I just went ahead and double-
checked, but sure enough, the SMTP address is there, and is correct.

Might creating a new SMTP alias, setting it as primary, then removing
the old one, wait a while, recreating the old SMTP and resetting the
primary again while removing the (temporary) second SMTP be a possible
solution?

What the heck... Just gonna try that...

Thanks sofar, any more thoughts or idea's... I'm open to 'm.

Neko-

Post by Lee Derbyshire [MVP]
When this affects one user, it usually means that they don't have an SMTP
address in the same domain as everyone else.
Lee.

[Neko-]

Unfortunatly... this did not change anything. So, the user still has
problems. In the mean time my Outlook client can use the webserver's
RPC over HTTP function properly, and so are the rest of the users able
to login...

I'm really stumped at what might be causing this...

Neko-

Post by Neko-
I checked that too... The user has just one SMTP address, and it is in
the same domain as the rest of the users. I just went ahead and double-
checked, but sure enough, the SMTP address is there, and is correct.
Might creating a new SMTP alias, setting it as primary, then removing
the old one, wait a while, recreating the old SMTP and resetting the
primary again while removing the (temporary) second SMTP be a possible
solution?
What the heck... Just gonna try that...
Thanks sofar, any more thoughts or idea's... I'm open to 'm.
Neko-

[Lee Derbyshire [MVP]]

Check the IIS Log to see which requested resource is returning the 401
status.

Post by Neko-
Unfortunatly... this did not change anything. So, the user still has
problems. In the mean time my Outlook client can use the webserver's
RPC over HTTP function properly, and so are the rest of the users able
to login...
I'm really stumped at what might be causing this...
Neko-

Post by Neko-
I checked that too... The user has just one SMTP address, and it is in
the same domain as the rest of the users. I just went ahead and double-
checked, but sure enough, the SMTP address is there, and is correct.
Might creating a new SMTP alias, setting it as primary, then removing
the old one, wait a while, recreating the old SMTP and resetting the
primary again while removing the (temporary) second SMTP be a possible
solution?
What the heck... Just gonna try that...
Thanks sofar, any more thoughts or idea's... I'm open to 'm.
Neko-

[Neko-]

2008-06-27 06:25:47 W3SVC1 <SERVERIP> GET /exchweb/img/newfldr.gif -
443 - <LOCALIP> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT
+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET
+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 200 0 0
2008-06-27 06:25:47 W3SVC1 <SERVERIP> GET /exchweb/img/replyall.gif -
443 - <LOCALIP> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT
+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET
+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 200 0 0
2008-06-27 06:25:47 W3SVC1 <SERVERIP> POST /exchweb/bin/auth/
owaauth.dll - 443 - <LOCALIP> Mozilla/4.0+(compatible;+MSIE
+7.0;+Windows+NT+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT
+5.1;+SV1)+;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR
+1.1.4322;+.NET+CLR+3.0.04506.648) 302 0 0
2008-06-27 06:25:47 W3SVC1 <SERVERIP> GET /exchange - 443 <USERNAME>
<LOCALIP> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR
+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 401 1 1329
2008-06-27 06:25:47 W3SVC1 <SERVERIP> GET /exchweb/bin/auth/
owalogon.asp url=https://webmail.domain.nl/exchange&reason=2 443 -
<LOCALIP> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR
+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 200 0 0

<USERNAME> - the problem user was entered
<LOCALIP> - The PC issueing the login attempt
<SERVERIP> - The IP address of the Frontend Server

I do note the 401 number in the fourth entry near the end. In the Web
logs, the last three numbers in each entry represent the status, the
substatus, and the Win32 status.

So the status on that one is 401, the substatus is 1, and the Win32
status is 1329.

Based on this it looks like the error listed here: http://support.microsoft.com/kb/907273

--------------------------------------

HTTP 401.1: Denied by invalid user credentials

Description

IIS failed to log on a user to execute the request. All requests must
be associated with a user, even if the request is anonymous.

Common reasons
* The wrong user name or password is provided. Identify the user who
failed to log on, and correct the user name or password.
* Kerberos authentication fails. For more information, click the
following article number to view the article in the Microsoft
Knowledge Base:

326985 (http://support.microsoft.com/kb/326985/) How to troubleshoot
Kerberos-related issues in IIS

Other useful Kerberos articles are as follows:

871179 (http://support.microsoft.com/kb/871179/) You receive an "HTTP
Error 401.1 - Unauthorized: Access is denied due to invalid
credentials" error message when you try to access a Web site that is
part of an IIS 6.0 application pool

Configuring Application Pool Identity with IIS 6.0 (IIS 6.0)

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/f05a7c2b-36b0-4b6e-ac7c-662700081f25.mspx
(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/
Library/IIS/f05a7c2b-36b0-4b6e-ac7c-662700081f25.mspx)

Integrated Windows Authentication (IIS 6.0)

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx
(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/
Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx)

Configuring Constrained Delegation for Kerberos (IIS 6.0)

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/df979570-81f6-4586-83c6-676bb005b13e.mspx
(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/
Library/IIS/df979570-81f6-4586-83c6-676bb005b13e.mspx)

* The local or domain policy or the user rights assignment prevents
the user from accessing the server. If the server is configured to
audit logon failures, there may be additional information in the
Security log. Refer to the following articles for the required user
rights:

812614 (http://support.microsoft.com/kb/812614/) Default permissions
and user rights for IIS 6.0
271071 (http://support.microsoft.com/kb/271071/) How to set required
NTFS permissions and user rights for an IIS 5.0 Web server
187506 (http://support.microsoft.com/kb/187506/) Required NTFS
permissions and user rights for IIS 4.0
832981 (http://support.microsoft.com/kb/832981/) Users cannot access
Web sites when the security event log is full
300549 (http://support.microsoft.com/kb/300549/) How to enable and
apply security auditing in Windows 2000

* This error may also occur when anonymous access is configured. This
may occur if the user name or password for the anonymous account that
is stored in the IIS metabase differs from the actual information
stored in the local user database (or the Active Directory directory
service, if a domain account is used). Resetting the password for the
account and in IIS resolves this problem.
* After you upgrade a server running IIS 5.0 to IIS 6.0, IIS is
running in IIS 5.0 compatibility mode. Once the server is switched to
IIS 6.0 isolation mode, you may see HTTP 401.1 errors on anonymous
requests. This occurs because of IIS 5.0 anonymous password
synchronization. To resolve this problem, set the
AnonymousPasswordSync metabase key to false, and reset the anonymous
user's password for the account and in IIS.
* For more information about this error, click the following article
numbers to view the articles in the Microsoft Knowledge Base:

896861 (http://support.microsoft.com/kb/896861/) You receive error
401.1 when you browse a Web site that uses Integrated Authentication
and is hosted on IIS 5.1 or IIS 6
304201 (http://support.microsoft.com/kb/304201/) Cannot access Web
sites or cannot start IIS services that run under non-local system
account and use Windows authentication with IIS
263140 (http://support.microsoft.com/kb/263140/) Anonymous and Basic
authentication fail when you connect to IIS 5.0 on a domain
controller
275167 (http://support.microsoft.com/kb/275167/) Anonymous access
fails with an HTTP 401.1 error after you join an IIS Windows 2000
domain

--------------------------------------

The username is correct, the password was reset, so that can't be the
cause.

I doubt it's a Kerberos authentication issue, since I'd expect a lot
more users having trouble with accessing webmail, and using the server
for their ActiveSync synchronisations.

The user is in an Active Directory folder that contains other users
that can access the webmail application. Policies seem to have no say
in the matter. It isn't a local policy either for the workstation PC,
since the user cannot access the webmail application from multiple
PC's. Among these is a PC that has NO domain access, and is running
solo in a workgroup. Group policies aren't active, and the user is
running it with local Administrative rights.

The anonymous access issue would seem to me like being indicative of a
lot more users seeing the problem occur. So I'm not convinced that is
the cause either.

The server was directly installed on IIS6, and is working normally for
the remaining users. The AnonymousPasswordSync doesn't seem to be the
cause there.

Based on the above I can't really say any one of the above sounds
plausible as a possible cause. All I can still try (although that will
probably be monday evening) would be to restart the actual Exchange
server, to see if that resolves anything (the FrontEnd server already
got a restart, but that did not resolve anything).

Searching onward I found this document: http://help.netop.com/support/errorcodes/win32_error_codes.htm

1329 Logon failure: user not allowed to log on to this computer.
ERROR_INVALID_WORKSTATION

Basically, again this tells me that authentication failed. You'd
almost say it hints at a problem with a policy still, although it
would have to be a policy local to either the FrontEnd or BackEnd
server. About the only one I can imagine being the cause here would be
the denial of access to OWA set forth from the ADUC, but I verified
that and it is allowed for the user. If it's a more global policy or
Group Policy object, I'd again expect it to compromise a lot more
people.

Due to the fact it's one user, I'd almost be convinced that it's in
the User settings of a policy. Scoured those, but can't find anything
out of the ordinary, plus the fact that someone in exactly the same
container, with the same policies has no issues logging in. Most
issues I can find hinting at this problem are talking about the IUSR
and IWAM accounts having problems. But if that's the case, I'm
expecting more then one user having issues. http://www.themssforum.com/IIS/Logon-failure-371769/

Any thoughts?

[Lee Derbyshire [MVP]]

Post by Neko-
2008-06-27 06:25:47 W3SVC1 <SERVERIP> GET /exchweb/img/newfldr.gif -
443 - <LOCALIP> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT
+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET
+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 200 0 0
2008-06-27 06:25:47 W3SVC1 <SERVERIP> GET /exchweb/img/replyall.gif -
443 - <LOCALIP> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT
+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET
+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 200 0 0
2008-06-27 06:25:47 W3SVC1 <SERVERIP> POST /exchweb/bin/auth/
owaauth.dll - 443 - <LOCALIP> Mozilla/4.0+(compatible;+MSIE
+7.0;+Windows+NT+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT
+5.1;+SV1)+;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR
+1.1.4322;+.NET+CLR+3.0.04506.648) 302 0 0
2008-06-27 06:25:47 W3SVC1 <SERVERIP> GET /exchange - 443 <USERNAME>
<LOCALIP> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR
+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 401 1 1329
2008-06-27 06:25:47 W3SVC1 <SERVERIP> GET /exchweb/bin/auth/
owalogon.asp url=https://webmail.domain.nl/exchange&reason=2 443 -
<LOCALIP> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR
+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 200 0 0
<USERNAME> - the problem user was entered
<LOCALIP> - The PC issueing the login attempt
<SERVERIP> - The IP address of the Frontend Server
I do note the 401 number in the fourth entry near the end. In the Web
logs, the last three numbers in each entry represent the status, the
substatus, and the Win32 status.
So the status on that one is 401, the substatus is 1, and the Win32
status is 1329.
http://support.microsoft.com/kb/907273
--------------------------------------
HTTP 401.1: Denied by invalid user credentials
Description
IIS failed to log on a user to execute the request. All requests must
be associated with a user, even if the request is anonymous.
Common reasons
* The wrong user name or password is provided. Identify the user who
failed to log on, and correct the user name or password.
* Kerberos authentication fails. For more information, click the
following article number to view the article in the Microsoft
326985 (http://support.microsoft.com/kb/326985/) How to troubleshoot
Kerberos-related issues in IIS
871179 (http://support.microsoft.com/kb/871179/) You receive an "HTTP
Error 401.1 - Unauthorized: Access is denied due to invalid
credentials" error message when you try to access a Web site that is
part of an IIS 6.0 application pool
Configuring Application Pool Identity with IIS 6.0 (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/f05a7c2b-36b0-4b6e-ac7c-662700081f25.mspx
(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/
Library/IIS/f05a7c2b-36b0-4b6e-ac7c-662700081f25.mspx)
Integrated Windows Authentication (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx
(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/
Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx)
Configuring Constrained Delegation for Kerberos (IIS 6.0)
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/df979570-81f6-4586-83c6-676bb005b13e.mspx
(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/
Library/IIS/df979570-81f6-4586-83c6-676bb005b13e.mspx)
* The local or domain policy or the user rights assignment prevents
the user from accessing the server. If the server is configured to
audit logon failures, there may be additional information in the
Security log. Refer to the following articles for the required user
812614 (http://support.microsoft.com/kb/812614/) Default permissions
and user rights for IIS 6.0
271071 (http://support.microsoft.com/kb/271071/) How to set required
NTFS permissions and user rights for an IIS 5.0 Web server
187506 (http://support.microsoft.com/kb/187506/) Required NTFS
permissions and user rights for IIS 4.0
832981 (http://support.microsoft.com/kb/832981/) Users cannot access
Web sites when the security event log is full
300549 (http://support.microsoft.com/kb/300549/) How to enable and
apply security auditing in Windows 2000
* This error may also occur when anonymous access is configured. This
may occur if the user name or password for the anonymous account that
is stored in the IIS metabase differs from the actual information
stored in the local user database (or the Active Directory directory
service, if a domain account is used). Resetting the password for the
account and in IIS resolves this problem.
* After you upgrade a server running IIS 5.0 to IIS 6.0, IIS is
running in IIS 5.0 compatibility mode. Once the server is switched to
IIS 6.0 isolation mode, you may see HTTP 401.1 errors on anonymous
requests. This occurs because of IIS 5.0 anonymous password
synchronization. To resolve this problem, set the
AnonymousPasswordSync metabase key to false, and reset the anonymous
user's password for the account and in IIS.
* For more information about this error, click the following article
896861 (http://support.microsoft.com/kb/896861/) You receive error
401.1 when you browse a Web site that uses Integrated Authentication
and is hosted on IIS 5.1 or IIS 6
304201 (http://support.microsoft.com/kb/304201/) Cannot access Web
sites or cannot start IIS services that run under non-local system
account and use Windows authentication with IIS
263140 (http://support.microsoft.com/kb/263140/) Anonymous and Basic
authentication fail when you connect to IIS 5.0 on a domain
controller
275167 (http://support.microsoft.com/kb/275167/) Anonymous access
fails with an HTTP 401.1 error after you join an IIS Windows 2000
domain
--------------------------------------
The username is correct, the password was reset, so that can't be the
cause.
I doubt it's a Kerberos authentication issue, since I'd expect a lot
more users having trouble with accessing webmail, and using the server
for their ActiveSync synchronisations.
The user is in an Active Directory folder that contains other users
that can access the webmail application. Policies seem to have no say
in the matter. It isn't a local policy either for the workstation PC,
since the user cannot access the webmail application from multiple
PC's. Among these is a PC that has NO domain access, and is running
solo in a workgroup. Group policies aren't active, and the user is
running it with local Administrative rights.
The anonymous access issue would seem to me like being indicative of a
lot more users seeing the problem occur. So I'm not convinced that is
the cause either.
The server was directly installed on IIS6, and is working normally for
the remaining users. The AnonymousPasswordSync doesn't seem to be the
cause there.
Based on the above I can't really say any one of the above sounds
plausible as a possible cause. All I can still try (although that will
probably be monday evening) would be to restart the actual Exchange
server, to see if that resolves anything (the FrontEnd server already
got a restart, but that did not resolve anything).
http://help.netop.com/support/errorcodes/win32_error_codes.htm
1329 Logon failure: user not allowed to log on to this computer.
ERROR_INVALID_WORKSTATION
Basically, again this tells me that authentication failed. You'd
almost say it hints at a problem with a policy still, although it
would have to be a policy local to either the FrontEnd or BackEnd
server. About the only one I can imagine being the cause here would be
the denial of access to OWA set forth from the ADUC, but I verified
that and it is allowed for the user. If it's a more global policy or
Group Policy object, I'd again expect it to compromise a lot more
people.
Due to the fact it's one user, I'd almost be convinced that it's in
the User settings of a policy. Scoured those, but can't find anything
out of the ordinary, plus the fact that someone in exactly the same
container, with the same policies has no issues logging in. Most
issues I can find hinting at this problem are talking about the IUSR
and IWAM accounts having problems. But if that's the case, I'm
expecting more then one user having issues.
http://www.themssforum.com/IIS/Logon-failure-371769/
Any thoughts?

I'm afraid not. 401;1 means that it did not accept the credentials, but
you've checked that. I assume that the user has the HTTP protocol enabled?
But that would produce a different message anyway.

[Neko-]

I assume you mean by that the availability of the OWA client being
switched on in ADUC?

Yes, that is enabled, and it's using the protocol defaults (same as
the rest of the users). I have no means of accessing the properties on
this specific Exchange Feature, so I'm pretty sure it can't be
something specific to this user under the properties themselves. If it
was, I'd have more problems with more users.

Tonight the mailserver backend will see a reboot, and we'll see if
that clears up the issue (I'm hoping it will, but am doubtful).

Thanks anyways for thinking along sofar. All the input is greatly
appreciated.

Post by Lee Derbyshire [MVP]
I'm afraid not. 401;1 means that it did not accept the credentials, but
you've checked that.  I assume that the user has the HTTP protocol enabled?
But that would produce a different message anyway.- Tekst uit oorspronkelijk bericht niet weergeven -
- Tekst uit oorspronkelijk bericht weergeven -

[Neko-]

Well... Restarted the backend server... no dice. Still doesn't work.
Then restarted the frontend/OWA server just to make sure. Still no go.
I can login as a different user, but I'm still unable to login as the
problem user.

Since I just got confronted with another strange quirk inside OWA (by
a user able to login) concerning adding attachments to new e-mails
(and I've just tested it myself with a 63 kB XLS on the local lan. The
OWA lets you select the file, and click 'attach', and then proceeds to
just sit there, until it times out, and that isn't even announced),
I'm starting to suspect the OWA as a whole :(

And the only way I know to resolve that, is by removing and
reinstalling Exchange as a whole :(

Anyone have any further idea's?

[Lee Derbyshire [MVP]]

You might try recreating the Exchange VDir first:

http://support.microsoft.com/kb/883380

Post by Neko-
Well... Restarted the backend server... no dice. Still doesn't work.
Then restarted the frontend/OWA server just to make sure. Still no go.
I can login as a different user, but I'm still unable to login as the
problem user.
Since I just got confronted with another strange quirk inside OWA (by
a user able to login) concerning adding attachments to new e-mails
(and I've just tested it myself with a 63 kB XLS on the local lan. The
OWA lets you select the file, and click 'attach', and then proceeds to
just sit there, until it times out, and that isn't even announced),
I'm starting to suspect the OWA as a whole :(
And the only way I know to resolve that, is by removing and
reinstalling Exchange as a whole :(
Anyone have any further idea's?

[Neko-]

That may resolve the attaching problem, although I don't expect it to
do much for the initial problem of the user himself.

Will have to take a look to see if I can implement that and when I can
do that... I'll keep you posted. Tks for the hint.

[Neko-]

Alright... Just had a go with this... It's been executed, and indeed
it worked as advertised. Tried out OWA, and it works like it's always
worked. That is... the user still has no login-possibility, while I do
have access under my own account, and the attachment problem in OWA is
also still there (both from the FrontEnd itself, aswell as from a
random client).

About the only thing I can imagine still worth a try would be to
reapply the ServicePack to the FrontEnd server... I'm not convinced a
complete removal, reinstall and reconfiguration of Exchange on the
FrontEnd will do me much good :(

[Lee Derbyshire [MVP]]

Post by Neko-
Alright... Just had a go with this... It's been executed, and indeed
it worked as advertised. Tried out OWA, and it works like it's always
worked. That is... the user still has no login-possibility, while I do
have access under my own account, and the attachment problem in OWA is
also still there (both from the FrontEnd itself, aswell as from a
random client).
About the only thing I can imagine still worth a try would be to
reapply the ServicePack to the FrontEnd server... I'm not convinced a
complete removal, reinstall and reconfiguration of Exchange on the
FrontEnd will do me much good :(

Try going directly to OWA on the BE server from the LAN. If it doesn't work
there, either, then it won't matter what you do to the FE.

[Roland Hall]

The steps I have had to take is to make sure security on the browser is not
too high so I put the OWA domain in the Trusted Sites list both HTTP and
HTTPS so unchecking ONLY HTTPS is required for non-HTTPS entries. I also
install the private certificate. In IE7, the cert will show an error and be
shown in red. You do have to accept the ActiveX control and turn off popups
for this location.

If a user could do this in the past, and cannot now, then this generally
points to a new wks, with a browser that has not previously connected. The
only recent issue I have had with the IE browser is IE7 upgrade solved an
issue because something as stuck in IE6. Normally that's not a fix but it
was in this case but not related to OWA.
--
Roland Hall


"Neko-" <[e-mail]> wrote in message news:36181ba0-679e-4ceb-9b82-***@m44g2000hsc.googlegroups.com...
Having an issue with one specific user having access problems to OWA.
Using an Exchange 2003 (on Windows 2003) configuration in a frontend/
backend configuration. Said user has been able to use the client
previously, but suddenly is unable to. Logging in through the Outlook
application on the desktop itself works without any problems.

* Verified permissions in ADUC, switched them off, applied, and
switched them back on, and applied. No change in behaviour.
* Added the domain before the username (i.e. domain\user) as a
loginname. No change in behaviour.
* Reset the password of the user to his own password. No change in
behaviour. (Caps aren’t being used either).
* Restarted the frontend server. No change in behaviour.

Logging in as a different user works fine (with or without the domain
added), it’s just one user having problems. I have found no records
of problems in the security eventlogs of the server, not on the front-
end OWA server, nor the backend Exchange server, nor the backend
Domain Controllers. No master/child domain configuration is active,
it’s all one domain. Issue is not limited to one computer (issue
occurs on multiple computers) and is not limited to IE7 being used,
since FireFox 3 exhibits the same behaviour: User1 can log in, and
user2 gets a notice. I therefore rule out cookies, certificates, SSL
and possible caching problems.

The user can login multiple times but appearantly isn’t authenticated.
Normally an account should lock after a few wrong passwords. In the
users case this does not happen. The screen drops back to the
loginscreen almost immidiatly. The error itself (translated from
dutch): You cannot be logged in by Outlook Web Access. Check if domain
\username and the password are correct, and try again.

Looked at
http://forums.whirlpool.net.au/forum-replies-archive.cfm/553775.html,
http://searchexchange.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid43_gci1191152,00.html.

Ran through the W3SVC1 log, located this:

2008-06-25 06:51:41 W3SVC1 10.0.0.1 POST /exchweb/bin/auth/owaauth.dll
- 443 - 192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT
+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET
+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 302 0 0
2008-06-25 06:51:41 W3SVC1 10.0.0.1 GET /exchange/ - 443 user1
192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR
+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 401 1 1329
2008-06-25 06:51:41 W3SVC1 10.0.0.1 GET /exchweb/bin/auth/owalogon.asp
url=https://webmail.domain.nl/exchange/&reason=2 443 - 192.168.0.2
Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/4.0+
(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR+2.0.50727;+.NET
+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR+3.0.04506.648) 200 0 0
2008-06-25 06:52:02 W3SVC1 10.0.0.1 POST /exchweb/bin/auth/owaauth.dll
- 443 - 192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT
+5.1;+Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET
+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 302 0 0
2008-06-25 06:52:02 W3SVC1 10.0.0.1 GET /exchange/ - 443 user2
192.168.0.2 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+Mozilla/
4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1)+;+.NET+CLR
+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+1.1.4322;+.NET+CLR
+3.0.04506.648) 200 0 0

The ‘reason=2’ seems to be the cause of the issue. Found the
following:

‘if the credentials are not correct, OWA will redirect back to exchweb/
bin/auth/owalogon.asp&reason=2, it will then display the message "You
could not be logged on to OWA".’

So it seems that for this one user, the OWA server doesn’t
authenticate, even if it does do this for a different user. Even if
the password has been reset, and is proven (through using the desktop
application of Outlook) to be correct.

Unfortunatly no recommended solutions. I’m almost considering possibly
removing the user completely, recreating him after a sync-period, and
reattaching the Exchange mailbox to his account. Either that, or
export the mailbox, remove the user, purge everything, and then
recreate the account and re-import the e-mail.

Anyone have any thoughts on this matter?

[Neko-]

Thanks for the input.

The security on the browser cannot be an issue. Cause of this is that
it does work under my account on my machine, but logging in as the
problem user on my machine fails. As such the security settings on
both the frontend server and the local workstation have been tested
and found to be appropriate for the communication to work.

The certificate is automatically installed with Active Directory, and
is working fine, since no notifications or said 'red' displays are
popping up. Since I can login under my own account, the certificate is
working, is valid, and is installed properly.

The user does not have a new workstation, moreso since it works with
one account on my workstation, but does not with his account. My
workstation is proven to be ready on a local scale to handle OWA. Also
logging in on his workstation with my account shows us a working OWA
with no problems, while again logging in under his account provides
problems.

Based on that I'm seriously considering the local client NOT to be a
problem, but a more centrally related problem. Since it however isn't
a uniform problem (that meaning more people have issues with it, and
just one person being affected) it's near to impossible to track the
problem down more then we've already done in this thread. That is...
unless I've missed something, or someone reading this gets hit with
inspiration and tosses up an interesting thing to check.

[Neko-]

I've gotten creative, and just decided to remove the entire mailbox an
all it's settings. Made a PST file backup, then removed the Exchange
mailbox from the ADUC. Ran the cleanup agent in Exchange, purged the
mailbox to completely remove it, and then waited 15 minutes. Recreated
the mailbox, configured it, then let it sync during 15 minutes. Went
to the users PC, started up Outllook 2002 and set things straight,
reimported the mail, and found that the mailbox got filled properly.
So the user has a recreated mailbox now, with his own data contained
therein.

Unfortunatly for OWA this does not change anything. User is still
unable to login. As a test, I removed the access rights to OWA on both
his account and mine. Waited 15 minutes for that change to sync
through, then tried it. On the working account the error 403 appears,
showing me that the page was not able to display. For the problem user
this changes nothing. So the error occurs before the actual
verification of the Exchange Features configured for the user.

About the only thing I can imagine I could try now that excludes
anything that affects multiple users (that being re-applying the
Service Pack for Exchange to the FrontEnd), is to remove the entire
user account, purge all profile settings, purge the mailbox, and
essentially wipe the slate clean, then re-create the user. This would
however entail quite a bit of work to get the whole profile filled
again, during which time the user has no means of being productive.
Not something I'd look forward to doing actually.

The suggestion on using the backend-server for OWA access kinda
slipped past my sight up to now. Fact is, the backend-server doesn't
actually run the OWA properly. I've provided it to be the same as for
the FrontEnd server, but for some reason it dumps me to a white
screen, depicting inbox and the like on the left, the textbar with the
'New email' at the top, commenting that it's loading the file list.
There are no graphics on the screen, and the pictures are reffered to
as being 'unavailable' (with the nice red X in 'm).

If anyone else has further suggestions on what we could try, I look
forward to hearing them.

[Lee Derbyshire [MVP]]

Post by Neko-
I've gotten creative, and just decided to remove the entire mailbox an
all it's settings. Made a PST file backup, then removed the Exchange
mailbox from the ADUC. Ran the cleanup agent in Exchange, purged the
mailbox to completely remove it, and then waited 15 minutes. Recreated
the mailbox, configured it, then let it sync during 15 minutes. Went
to the users PC, started up Outllook 2002 and set things straight,
reimported the mail, and found that the mailbox got filled properly.
So the user has a recreated mailbox now, with his own data contained
therein.
Unfortunatly for OWA this does not change anything. User is still
unable to login. As a test, I removed the access rights to OWA on both
his account and mine. Waited 15 minutes for that change to sync
through, then tried it. On the working account the error 403 appears,
showing me that the page was not able to display. For the problem user
this changes nothing. So the error occurs before the actual
verification of the Exchange Features configured for the user.
About the only thing I can imagine I could try now that excludes
anything that affects multiple users (that being re-applying the
Service Pack for Exchange to the FrontEnd), is to remove the entire
user account, purge all profile settings, purge the mailbox, and
essentially wipe the slate clean, then re-create the user. This would
however entail quite a bit of work to get the whole profile filled
again, during which time the user has no means of being productive.
Not something I'd look forward to doing actually.
The suggestion on using the backend-server for OWA access kinda
slipped past my sight up to now. Fact is, the backend-server doesn't
actually run the OWA properly. I've provided it to be the same as for
the FrontEnd server, but for some reason it dumps me to a white
screen, depicting inbox and the like on the left, the textbar with the
'New email' at the top, commenting that it's loading the file list.
There are no graphics on the screen, and the pictures are reffered to
as being 'unavailable' (with the nice red X in 'm).
If anyone else has further suggestions on what we could try, I look
forward to hearing them.

If the BE OWA doesn't work 100% correctly, then that's not really an issue
if as long as it continues to work through the FE. The FE proxies your OWA
requests into the OWA directory on the BE, but the supporting .js files
still come from the FE, and you may find that the problems on the BE are
related to the security settings for the zone that IE puts the BE in,
compared to the FE.

What is more interesting is how the BE behaves when the affected user tries
to use it. Do they still have the same problem that they get from the FE,
or do they see the same results as when someone else logs in.

[Neko-]

As stated, the BE doesn't actually succeed in starting the OWA. As to
accessing directly, works for all users using Outlook on their
clients.

While the cause of the BE malfunction eludes me at the moment, I agree
that as long as it works for the majority of users on the FE there's
not really a problem in using it. A test on the BE would be a good
test if it worked to see if the communication between the FE and BE
was to blame (I doubt it, since that would cause problems to ALL users
on the FE, and it's only 1 user having issues to my knowledge).

Like I said, about the only thing I can imagine is to remove and re-
create the whole user account by now. But since I have a vacation
coming up, I'm seriously considering postponing this till after said
vacation to prevent issues arising during my vacation.

[Lee Derbyshire [MVP]]

It would have been interesting to see if the affected user could actually
log into the BE server, though. Since the FE proxies OWA requests to the BE
server, if the user is denied access to the BE by something, then it may
look as though the problem is coming from the FE, since IIS on the FE
impersonates the logged-on user when directing the proxied requests to the
BE.

Post by Neko-
As stated, the BE doesn't actually succeed in starting the OWA. As to
accessing directly, works for all users using Outlook on their
clients.
While the cause of the BE malfunction eludes me at the moment, I agree
that as long as it works for the majority of users on the FE there's
not really a problem in using it. A test on the BE would be a good
test if it worked to see if the communication between the FE and BE
was to blame (I doubt it, since that would cause problems to ALL users
on the FE, and it's only 1 user having issues to my knowledge).
Like I said, about the only thing I can imagine is to remove and re-
create the whole user account by now. But since I have a vacation
coming up, I'm seriously considering postponing this till after said
vacation to prevent issues arising during my vacation.

[M***@gmail.com]

Post by Lee Derbyshire [MVP]
It would have been interesting to see if the affected user could actually
log into the BE server, though.  Since the FE proxies OWA requests to the BE
server, if the user is denied access to the BE by something, then it may
look as though the problem is coming from the FE, since IIS on the FE
impersonates the logged-on user when directing the proxied requests to the
BE.

Post by Neko-
As stated, the BE doesn't actually succeed in starting the OWA. As to
accessing directly, works for all users using Outlook on their
clients.
While the cause of the BE malfunction eludes me at the moment, I agree
that as long as it works for the majority of users on the FE there's
not really a problem in using it. A test on the BE would be a good
test if it worked to see if the communication between the FE and BE
was to blame (I doubt it, since that would cause problems to ALL users
on the FE, and it's only 1 user having issues to my knowledge).
Like I said, about the only thing I can imagine is to remove and re-
create the whole user account by now. But since I have a vacation
coming up, I'm seriously considering postponing this till after said
vacation to prevent issues arising during my vacation.- Hide quoted text -

- Show quoted text -

Just had the same issue with OWA. Here is the resolve:

1. Go to Active Directroy Users and Computers and find and open the
user account who cannot logon to OWA
2. Click on the "Account" tab, and the "Log on To" button
3. Change the bullet point from "the following computers" to "all
computers"

Good Luck
-mrain1

[Neko-]

Post by M***@gmail.com
1. Go to Active Directroy Users and Computers and find and open the
user account who cannot logon to OWA
2. Click on the "Account" tab, and the "Log on To" button
3. Change the bullet point from "the following computers" to "all
computers"
Good Luck
-mrain1- Tekst uit oorspronkelijk bericht niet weergeven -

Well... I'm stunned...

I know this setting, and I know I'm staying well away from it as a
general policy if I can help it, to prevent just these kinds of
problems from occurring. Reading your solution caused my first
reaction to be: Can't be that, I didn't set it, we don't use it, so
it's still at the default (that being everyone can log in on any PC).

Nevertheless, I checked... and was floored to find out that's EXACTLY
what was causing the issue. Removed it, and tested it, and sure
enough, it works normally again. :D

I've spoken to my collegue's who both can't recall ever setting that
flag on any accounts, but I'm sure as heck not gonna fall for this a
second time.

To everyone contributing to this thread and helping me think things
through: THANK YOU! All your thoughts, suggestions, and whatnot are
greatly appreciated!

[JoeR]

I don't know the root cause of this issue, but re-creating the user account
and re-attaching it to the mailbox resolved the issue for the problem user.
How and why it broke for only certain users is still a mystery.

Post by Neko-
Thanks for the input.
The security on the browser cannot be an issue. Cause of this is that
it does work under my account on my machine, but logging in as the
problem user on my machine fails. As such the security settings on
both the frontend server and the local workstation have been tested
and found to be appropriate for the communication to work.
The certificate is automatically installed with Active Directory, and
is working fine, since no notifications or said 'red' displays are
popping up. Since I can login under my own account, the certificate is
working, is valid, and is installed properly.
The user does not have a new workstation, moreso since it works with
one account on my workstation, but does not with his account. My
workstation is proven to be ready on a local scale to handle OWA. Also
logging in on his workstation with my account shows us a working OWA
with no problems, while again logging in under his account provides
problems.
Based on that I'm seriously considering the local client NOT to be a
problem, but a more centrally related problem. Since it however isn't
a uniform problem (that meaning more people have issues with it, and
just one person being affected) it's near to impossible to track the
problem down more then we've already done in this thread. That is...
unless I've missed something, or someone reading this gets hit with
inspiration and tosses up an interesting thing to check.

[Lisa M]

Hello, I'm wondering whether you ever figured out an answer to your problem.
I am experiencing the exact same situation: OWA/OMA/Activesync have been
running for months and working just fine. Now, a couple of users can no
longer access these services. Only 2 that I know of out of about 300. Both
users can still access their mailboxes using Outlook. Everything points to a
permissions issue, but nothing has change for these users. If I add one of
the users to the domain admins group, they can log in to OWA.

Did you ever find a fix? I had a third user w/this issue and I ended up
deleting a nd recreating his account, something I don't want to have to do on
a regular basis.

Thanks in advance,
Lisa M

Post by Neko-
Thanks for the input.
The security on the browser cannot be an issue. Cause of this is that
it does work under my account on my machine, but logging in as the
problem user on my machine fails. As such the security settings on
both the frontend server and the local workstation have been tested
and found to be appropriate for the communication to work.
The certificate is automatically installed with Active Directory, and
is working fine, since no notifications or said 'red' displays are
popping up. Since I can login under my own account, the certificate is
working, is valid, and is installed properly.
The user does not have a new workstation, moreso since it works with
one account on my workstation, but does not with his account. My
workstation is proven to be ready on a local scale to handle OWA. Also
logging in on his workstation with my account shows us a working OWA
with no problems, while again logging in under his account provides
problems.
Based on that I'm seriously considering the local client NOT to be a
problem, but a more centrally related problem. Since it however isn't
a uniform problem (that meaning more people have issues with it, and
just one person being affected) it's near to impossible to track the
problem down more then we've already done in this thread. That is...
unless I've missed something, or someone reading this gets hit with
inspiration and tosses up an interesting thing to check.