We're working on an application that uses the Virtual Server API.
If the Virtual server is NOT within a domain but on a "standalone" server,
can somebody that is on a different system login to it using the APIs?
I know that as a work around we could create a user on the "different"
system with the same username/password as on the server and bypass the
security like that, but we would like to be able to realy authenticated and
this by passing credentials (username/password) of a user that is only
defined on the server. Is this possible.



dirk.

Nothing in Virtual Server that supports this. If you stick with the COM API,
client and VS host must be in the same security domain (domain/forest).
Basically, there is no workgroup support.

Matthijs

"Dirk B" wrote:

> We're working on an application that uses the Virtual Server API.
> If the Virtual server is NOT within a domain but on a "standalone" server,
> can somebody that is on a different system login to it using the APIs?
> I know that as a work around we could create a user on the "different"
> system with the same username/password as on the server and bypass the
> security like that, but we would like to be able to realy authenticated and
> this by passing credentials (username/password) of a user that is only
> defined on the server. Is this possible.
>
>
>
> dirk.
>
>
>

When you say "if you stick to the COM API", can I undertand from that, that
there are other options then using the COM API?



dirk.

"Matthijs ten Seldam [MSFT]"
<MatthijstenSeldamMSFT@discussions.microsoft.com > wrote in message
news:4BF93AE9-8A23-4B27-B98F-6B633AEECEA3@microsoft.com...
> Nothing in Virtual Server that supports this. If you stick with the COM
> API,
> client and VS host must be in the same security domain (domain/forest).
> Basically, there is no workgroup support.
>
> Matthijs
>
> "Dirk B" wrote:
>
>> We're working on an application that uses the Virtual Server API.
>> If the Virtual server is NOT within a domain but on a "standalone"
>> server,
>> can somebody that is on a different system login to it using the APIs?
>> I know that as a work around we could create a user on the "different"
>> system with the same username/password as on the server and bypass the
>> security like that, but we would like to be able to realy authenticated
>> and
>> this by passing credentials (username/password) of a user that is only
>> defined on the server. Is this possible.
>>
>>
>>
>> dirk.
>>
>>
>>

Yes, basically you need to set COM security on every access of an object.
Virtual Server does not provide something like a 'connect as' option
(method) like for example ISA Server.
If you set the security globally (many samples do, also easy because you
only do that once) then the credential must be valid in both client and
server environment.
So it is possible to work with an alternate credential but it takes a lot of
effort in your code.

Matthijs

"Dirk B" wrote:

> When you say "if you stick to the COM API", can I undertand from that, that
> there are other options then using the COM API?
>
>
>
> dirk.
>
> "Matthijs ten Seldam [MSFT]"
> <MatthijstenSeldamMSFT@discussions.microsoft.com > wrote in message
> news:4BF93AE9-8A23-4B27-B98F-6B633AEECEA3@microsoft.com...
> > Nothing in Virtual Server that supports this. If you stick with the COM
> > API,
> > client and VS host must be in the same security domain (domain/forest).
> > Basically, there is no workgroup support.
> >
> > Matthijs
> >
> > "Dirk B" wrote:
> >
> >> We're working on an application that uses the Virtual Server API.
> >> If the Virtual server is NOT within a domain but on a "standalone"
> >> server,
> >> can somebody that is on a different system login to it using the APIs?
> >> I know that as a work around we could create a user on the "different"
> >> system with the same username/password as on the server and bypass the
> >> security like that, but we would like to be able to realy authenticated
> >> and
> >> this by passing credentials (username/password) of a user that is only
> >> defined on the server. Is this possible.
> >>
> >>
> >>
> >> dirk.
> >>
> >>
> >>
>
>
>