Connecting to Project Server

[Bhatta]

I have a few users (project managers)on a client site in
different domain than the one project server is residing
on they need to modify and publish projects. they can
access project web access just fine.
I have Project server 2003 set to use windows integrated
authentication. Is there a way to configure project
professional 2003 to successfully connect to the project
server. When trying to set the connection up project
authentication defaults to the account the user already
logged in to for example xyz\jdoe when in fact it should
use abc\jdoe. I couldn't find a way to change it because
it is grayed out.
Any help to resolve this will be greatly appreciated.
Thank you.

Ben

 

[Gary M]

You may want a second opinion but in the Open Enterprise Resources we always
specify abc\usergary for authentication (for a specific reason). Have you
tried this?

HTH,
Gary

 

[Guest]

The account is set like that abc\jdoe but the abc is for
the domain where the project server is, and the user is
coming with credentials from domain xyz (xyz\jdoe)

 

[Gary L. Chefetz \(MVP\)]

It's not safe or practical to use Project this way. It's better to provide a
remote desktop to the users either through terminal services or something as
simple as an XP workstation.

--

Gary L. Chefetz, MVP
"We wrote the book on Project Server
http://www.msprojectexperts.com

-

 

[Enomagic]

We have been looking into this issue in depth since this issue directly
affects the ability to provide a hosted service. The results of enquiries
and consultation with MS the result what you are trying to do is not easily
possible. (please correct me MVPs if you are aware of a different approach).

Essentially, the client is hard coded to only allow two ways to logon -
using the windows account that you logged onto the client machine with, or a
project server authentication account. For our purposes we needed to get
windows logon working - we didn't want to use project auth since having
details in AD means we can manage users with our existing provisioning
systems.

As such, for users in different domains, the windows logon onto project
server from the client application is not an available option . So the only
options were:
1) for each project server, create limited number project auth accounts that
allow connection from clients. This is not ideal or easily manageable, and
we found would mean some people would have 2 accounts (a windows one and a
proj auth one) where the proj auth one would only be used for remote access.
It should be noted that we have not implemented this because of security
concerns - project professional does require an odbc connection to the
database so we weren't prepared to open the db server to the internet. A
vpn might get around this.
2) Host the client app. The end result is to host the project professional
client on a terminal server in the same domain as the server. The user
simply logons on with a term serv client and gets to use the app that way.
Port 3389 access is required and should be noted.

So I am sorry to say that your current attempted aim is probably not
possible, without rethinking how your users currently use your deployment.
IMHO - get a terminal server, get the user to vpn into your office
environemnt (or a less secure solution is make your terminal server
available directly - don't do this without a proper security eval), install
the client app on that server - then they will have secure access remotely.

Hope this clears up how things currently are. Please feel free to lobby MS
to get more hoster friendly EPM on the product roadmap!!

Enomagic

 

[Guest]

Thanks for the reply Gary, but what do you mean
by "something as simple as an XP workstation".
The users in question have Windows XP workstations.
Thank you

 

[Guest]

Thank you very much for the explanations.

-----Original Message-----
We have been looking into this issue in depth since this issue directly
affects the ability to provide a hosted service. The results of enquiries
and consultation with MS the result what you are trying to do is not easily
possible. (please correct me MVPs if you are aware of a different approach).

Essentially, the client is hard coded to only allow two ways to logon -
using the windows account that you logged onto the client machine with, or a
project server authentication account. For our purposes we needed to get
windows logon working - we didn't want to use project auth since having
details in AD means we can manage users with our existing provisioning
systems.

As such, for users in different domains, the windows logon onto project
server from the client application is not an available option . So the only
options were:
1) for each project server, create limited number project auth accounts that
allow connection from clients. This is not ideal or easily manageable, and
we found would mean some people would have 2 accounts (a windows one and a
proj auth one) where the proj auth one would only be used for remote access.
It should be noted that we have not implemented this because of security
concerns - project professional does require an odbc connection to the
database so we weren't prepared to open the db server to the internet. A
vpn might get around this.
2) Host the client app. The end result is to host the project professional
client on a terminal server in the same domain as the server. The user
simply logons on with a term serv client and gets to use the app that way.
Port 3389 access is required and should be noted.

So I am sorry to say that your current attempted aim is probably not
possible, without rethinking how your users currently use your deployment.
IMHO - get a terminal server, get the user to vpn into your office
environemnt (or a less secure solution is make your terminal server
available directly - don't do this without a proper security eval), install
the client app on that server - then they will have secure access remotely.

Hope this clears up how things currently are. Please feel free to lobby MS
to get more hoster friendly EPM on the product roadmap!!

Enomagic





.

 

[Gary L. Chefetz \(MVP\)]

I meant, it's possible to connect to a workstation remotely and use it to
run Project .

--

Gary L. Chefetz, MVP
"We wrote the book on Project Server
http://www.msprojectexperts.com

-