[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

reddy

8/23/2003 4:43:00 AM

Hi,

We have developed a webservice that retrieves Free/Busy information from the
Exchange Server and returns it to the client.

The webservice and webclient are installed on one domain. Exchange Server
is running in the other domain. Both the domains are in different forests.

Now when we try to call the webservice either directly or through webclient,
we are getting the following error
'401 Remote server denied access'.

The webservice and webclient are running under Anonylous access and the
credentials to log onto the Exchange Server are provided through an external
text file.

The web service works ok when both the service and Exchange server are in
the same domain or under the same parent domain. The cross domain trusts
are in place as is evident from
successful mapping of shares on either side.

What could be the problem? Any help is highly appreciated.

Thanks,

Reddy
I.S.Solutions P. Ltd.



2 Answers

reddy

8/23/2003 11:54:00 AM

0

Hi Frank,

Thanks for the info. But we are not able torun the webservice as an account
in the other domain. Where can we find more info on this and also on
creating mirrored account.

Reddy

Frank Drebin <noemail@imsickofspam.com> wrote in message
news:6qC1b.30344$Vx2.13649939@newssvr28.news.prodigy.com...
>You need to have the webservice run as an account (via ADSI) that has
proper
>authority on the Exchange server -or- create a mirrored account on the
>webservice machine - so that when it goes to talk to the Exchange server -
>it will find a matching account and let you in.
>
>The way it is right now, when the webservice goes to attach to the Exchange
>box - it has no idea who you are. Or - it knows who you are (an
>authenticated user, from a machine I don't trust) but won't let you in..
>
>hth
>
>"reddy" <support@issolutionsin.com> wrote in message
>news:Oc0WxFTaDHA.2284@TK2MSFTNGP10.phx.gbl...
>> Hi,
>>
>> We have developed a webservice that retrieves Free/Busy information from
>the
>> Exchange Server and returns it to the client.
>>
>> The webservice and webclient are installed on one domain. Exchange
Server
>> is running in the other domain. Both the domains are in different
>forests.
>>
>> Now when we try to call the webservice either directly or through
>webclient,
>> we are getting the following error
>> '401 Remote server denied access'.
>>
>> The webservice and webclient are running under Anonylous access and the
>> credentials to log onto the Exchange Server are provided through an
>external
>> text file.
>>
>> The web service works ok when both the service and Exchange server are in
>> the same domain or under the same parent domain. The cross domain trusts
>> are in place as is evident from
>> successful mapping of shares on either side.
>>
>> What could be the problem? Any help is highly appreciated.
>>
>> Thanks,
>>
>> Reddy
>> I.S.Solutions P. Ltd.
>>
>>
>>
>
>


Frank Drebin

8/23/2003 12:38:00 PM

0

Reddy,

Do you mean you don't know how or that you aren't allowed for some reason?
What I was saying below was almost the same thing - you would need to set
IIS to run as a different person, a person that BOTH machine know. So either
point both machines to an account (even if you create a new one called
"WebSvc Account") in Active Directory.

Or - create an account called "WebSvc Account" on the Exchange server, and
then create an account called "WebSvc Account" on the web server. Set the
Web Service IIS application to run as "WebSvc Account" - and on the Exchange
server, give that account whatever privileges the Web Service needs over
there. You need to make sure, that when the web service talks to the
Exchange server - they both see that that Web Service is a real, trusted
account... OR - you can have the web service run as this untrusted account
and talk to the Exchange server - and when it gets there, even if the
Exchange server doesn't know who you are or trust you - if the username and
password matches exactly to an account that is on that box, you will be let
it...

Another thing you may try, is authenticating programatically... not sure if
this will work though. Here is a working class:

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

using System;
using System.Runtime.InteropServices;

[StructLayout(LayoutKind.Sequential)]
public struct NETRESOURCEA
{
public int dwScope;
public int dwType;
public int dwDisplayType;
public int dwUsage;
[ MarshalAs (UnmanagedType.LPStr)]
public string lpLocalName;
[ MarshalAs (UnmanagedType.LPStr)]
public string lpRemoteName;
[ MarshalAs (UnmanagedType.LPStr)]
public string lpComment;
[ MarshalAs (UnmanagedType.LPStr)]
public string lpProvider;
public override String ToString()
{
String str = "LocalName: " + lpLocalName + " RemoteName: " + lpRemoteName
+ " Comment: " + lpComment + " lpProvider: " + lpProvider;
return(str);
}
}

class Authentication
{
[DllImport("mpr.dll")]
private static extern int WNetAddConnection2A(
[MarshalAs(UnmanagedType.LPArray)] NETRESOURCEA[] lpNetResource,
[MarshalAs(UnmanagedType.LPStr)] string lpPassword,
[MarshalAs(UnmanagedType.LPStr)] string UserName,
int dwFlags);
[DllImport("mpr.dll")]
private static extern int WNetCancelConnection2(
[MarshalAs(UnmanagedType.LPStr)] string lpName,
int dwFlags,
bool fForce);

public static int ValidateUser(string Server,string User,string Password)
{
NETRESOURCEA [] n = new NETRESOURCEA[1];
n[0] = new NETRESOURCEA();
n[0].dwType = 0;
int dwFlags = 1;
n[0].lpLocalName = null;
n[0].lpRemoteName = @"\\" + Server + @"\IPC$";
n[0].lpProvider = null;

int res = WNetAddConnection2A( n, Password, User, dwFlags );
return res;
}
public static void CancelConnection(string Connection)
{
WNetCancelConnection2(Connection, 0, true);
}
}

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

And to use this, you just do this:

int intRet =
Authentication.ValidateUser("MyServer","hsimpson","donuts");
if ( intRet == 0 )
{
// login was good
}
else
{
// login was bad - error number is intRet
}


hth


"reddy" <support@issolutionsin.com> wrote in message
news:uEmwT2WaDHA.2588@TK2MSFTNGP09.phx.gbl...
> Hi Frank,
>
> Thanks for the info. But we are not able torun the webservice as an
account
> in the other domain. Where can we find more info on this and also on
> creating mirrored account.
>
> Reddy
>
> Frank Drebin <noemail@imsickofspam.com> wrote in message
> news:6qC1b.30344$Vx2.13649939@newssvr28.news.prodigy.com...
> >You need to have the webservice run as an account (via ADSI) that has
> proper
> >authority on the Exchange server -or- create a mirrored account on the
> >webservice machine - so that when it goes to talk to the Exchange
server -
> >it will find a matching account and let you in.
> >
> >The way it is right now, when the webservice goes to attach to the
Exchange
> >box - it has no idea who you are. Or - it knows who you are (an
> >authenticated user, from a machine I don't trust) but won't let you in..
> >
> >hth
> >
> >"reddy" <support@issolutionsin.com> wrote in message
> >news:Oc0WxFTaDHA.2284@TK2MSFTNGP10.phx.gbl...
> >> Hi,
> >>
> >> We have developed a webservice that retrieves Free/Busy information
from
> >the
> >> Exchange Server and returns it to the client.
> >>
> >> The webservice and webclient are installed on one domain. Exchange
> Server
> >> is running in the other domain. Both the domains are in different
> >forests.
> >>
> >> Now when we try to call the webservice either directly or through
> >webclient,
> >> we are getting the following error
> >> '401 Remote server denied access'.
> >>
> >> The webservice and webclient are running under Anonylous access and the
> >> credentials to log onto the Exchange Server are provided through an
> >external
> >> text file.
> >>
> >> The web service works ok when both the service and Exchange server are
in
> >> the same domain or under the same parent domain. The cross domain
trusts
> >> are in place as is evident from
> >> successful mapping of shares on either side.
> >>
> >> What could be the problem? Any help is highly appreciated.
> >>
> >> Thanks,
> >>
> >> Reddy
> >> I.S.Solutions P. Ltd.
> >>
> >>
> >>
> >
> >
>
>