Ureader.com  
Microsoft software help and Community
   home   |   control panel login   |   archive   |  
 
Others
cms.evaluation
cms.general
comm.businessdesk
comm.campaigns_csf
comm.catalog
comm.datawarehousing
comm.deploy.
comm.general
comm.sdk
comm.solutionsites
comm.userprofilemgt
commerce.analysis
crm
crm.deployment
crm.developer
hiserver.general
mobility.miserver
sharep.portal.config
sharep.portal.dev
sharep.portal.docmgmt.
sharep.portal.installation
sharep.portal.sdk
sharep.portal.search
sharep.team.caml
sharep.teamservices
sharep.windowsservices
sharep.winservices.dev
sharepoint.portalserver
siteserv.knowledgemgr
siteserver.analysis
siteserver.commerce
siteserver.css
siteserver.general
siteserver.publishing
siteserver.sdk
siteserver.search
site-server.site-mgmt
site-server.webpost
  
 
date: Thu, 3 Jul 2008 13:45:07 -0700 (PDT),    group: microsoft.public.sharepoint.portalserver        back       


MOSS Hosting   
Hello All

We host a few sharepoint 2007 sites for a few clients (SPLA). The way
our setup is configured at the moment is that we configure their top
level site for them and just provide them with an access URL,  they
dont get access to Central Admin. Therefore If anything is required to
be enabled on the server, for example the InfoPath forms service, they
request this via a support ticket.

We now have the requirement to provide a dedicated service to a
specific customer who wants to be able to use Central Admin. The
problem as I see it is that the dedicated service is in our hosting AD
domain and therefore they could cause problems and also probably
browse our AD (?)

Is there a way,apart from creating them in their own domain, that we
can stop them interogating our hosting AD?

What are the real risks if we let them lose with central admin on a
MOSS server in our hosting domain.

Any thoughts and advice would be most welcome.

Thanks

Andy
date: Thu, 3 Jul 2008 13:45:07 -0700 (PDT)   author:   AJ

Re: MOSS Hosting   
What exactly are they wanting to access via central admin.  I certainly 
wouldn't let them near it just because they asked!

Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog


"AJ"  wrote in message 
news:079f51c2-4085-43c4-9aaa-0b80aeafb973@8g2000hse.googlegroups.com...
> Hello All
>
> We host a few sharepoint 2007 sites for a few clients (SPLA). The way
> our setup is configured at the moment is that we configure their top
> level site for them and just provide them with an access URL,  they
> dont get access to Central Admin. Therefore If anything is required to
> be enabled on the server, for example the InfoPath forms service, they
> request this via a support ticket.
>
> We now have the requirement to provide a dedicated service to a
> specific customer who wants to be able to use Central Admin. The
> problem as I see it is that the dedicated service is in our hosting AD
> domain and therefore they could cause problems and also probably
> browse our AD (?)
>
> Is there a way,apart from creating them in their own domain, that we
> can stop them interogating our hosting AD?
>
> What are the real risks if we let them lose with central admin on a
> MOSS server in our hosting domain.
>
> Any thoughts and advice would be most welcome.
>
> Thanks
>
> Andy
date: Fri, 4 Jul 2008 20:07:18 +0100   author:   John Timney \(MVP\)

Re: MOSS Hosting   
On 4 Jul, 20:07, "John Timney \(MVP\)" 
wrote:
> What exactly are they wanting to access via central admin.  I certainly
> wouldn't let them near it just because they asked!
>
> Regards
>
> John Timney (MVP)http://www.johntimney.comhttp://www.johntimney.com/blog
>
> "AJ"  wrote in message
>
> news:079f51c2-4085-43c4-9aaa-0b80aeafb973@8g2000hse.googlegroups.com...
>
>
>
> > Hello All
>
> > We host a few sharepoint 2007 sites for a few clients (SPLA). The way
> > our setup is configured at the moment is that we configure their top
> > level site for them and just provide them with an access URL,  they
> > dont get access to Central Admin. Therefore If anything is required to
> > be enabled on the server, for example the InfoPath forms service, they
> > request this via a support ticket.
>
> > We now have the requirement to provide a dedicated service to a
> > specific customer who wants to be able to use Central Admin. The
> > problem as I see it is that the dedicated service is in our hosting AD
> > domain and therefore they could cause problems and also probably
> > browse our AD (?)
>
> > Is there a way,apart from creating them in their own domain, that we
> > can stop them interogating our hosting AD?
>
> > What are the real risks if we let them lose with central admin on a
> > MOSS server in our hosting domain.
>
> > Any thoughts and advice would be most welcome.
>
> > Thanks
>
> > Andy- Hide quoted text -
>
> - Show quoted text -

Hi John
Thanks for your input. I think this is the stance that we are going to
take. However I have seen other companies that offer full central
admin access so I was also curious to how they did this. I guess they
deployed a seperate AD forest specifically for that customer, or is
there someway this can be done using forms based authentication and
SQL server as the accounts repository?
Thanks
Andy
date: Mon, 7 Jul 2008 12:27:20 -0700 (PDT)   author:   AJ

Re: MOSS Hosting   
Or, possibly, they deployed separate virtual machines for the clients, 
either setup with their own AD, or using the server's SAM for 
authentication.

-callahan
"AJ"  wrote in message 
news:cbfe6b03-1278-4043-b98b-7fb2722cca4b@k30g2000hse.googlegroups.com...
On 4 Jul, 20:07, "John Timney \(MVP\)" 
wrote:
> What exactly are they wanting to access via central admin. I certainly
> wouldn't let them near it just because they asked!
>
> Regards
>
> John Timney (MVP)http://www.johntimney.comhttp://www.johntimney.com/blog
>
> "AJ"  wrote in message
>
> news:079f51c2-4085-43c4-9aaa-0b80aeafb973@8g2000hse.googlegroups.com...
>
>
>
> > Hello All
>
> > We host a few sharepoint 2007 sites for a few clients (SPLA). The way
> > our setup is configured at the moment is that we configure their top
> > level site for them and just provide them with an access URL, they
> > dont get access to Central Admin. Therefore If anything is required to
> > be enabled on the server, for example the InfoPath forms service, they
> > request this via a support ticket.
>
> > We now have the requirement to provide a dedicated service to a
> > specific customer who wants to be able to use Central Admin. The
> > problem as I see it is that the dedicated service is in our hosting AD
> > domain and therefore they could cause problems and also probably
> > browse our AD (?)
>
> > Is there a way,apart from creating them in their own domain, that we
> > can stop them interogating our hosting AD?
>
> > What are the real risks if we let them lose with central admin on a
> > MOSS server in our hosting domain.
>
> > Any thoughts and advice would be most welcome.
>
> > Thanks
>
> > Andy- Hide quoted text -
>
> - Show quoted text -

Hi John
Thanks for your input. I think this is the stance that we are going to
take. However I have seen other companies that offer full central
admin access so I was also curious to how they did this. I guess they
deployed a seperate AD forest specifically for that customer, or is
there someway this can be done using forms based authentication and
SQL server as the accounts repository?
Thanks
Andy
date: Mon, 7 Jul 2008 17:06:33 -0400   author:   callahan

Re: MOSS Hosting   
I see no issue giving them access to their SSP site, if they have one.
The problem here is to accomodate their request might be too late as this 
would have been planned in the planning stage with all the different 
options. If it was to process, look at migrating their environment to a new 
MOSS instance


"callahan"  wrote in message 
news:ukxwbVH4IHA.4908@TK2MSFTNGP04.phx.gbl...
> Or, possibly, they deployed separate virtual machines for the clients, 
> either setup with their own AD, or using the server's SAM for 
> authentication.
>
> -callahan
> "AJ"  wrote in message 
> news:cbfe6b03-1278-4043-b98b-7fb2722cca4b@k30g2000hse.googlegroups.com...
> On 4 Jul, 20:07, "John Timney \(MVP\)" 
> wrote:
>> What exactly are they wanting to access via central admin. I certainly
>> wouldn't let them near it just because they asked!
>>
>> Regards
>>
>> John Timney (MVP)http://www.johntimney.comhttp://www.johntimney.com/blog
>>
>> "AJ"  wrote in message
>>
>> news:079f51c2-4085-43c4-9aaa-0b80aeafb973@8g2000hse.googlegroups.com...
>>
>>
>>
>> > Hello All
>>
>> > We host a few sharepoint 2007 sites for a few clients (SPLA). The way
>> > our setup is configured at the moment is that we configure their top
>> > level site for them and just provide them with an access URL, they
>> > dont get access to Central Admin. Therefore If anything is required to
>> > be enabled on the server, for example the InfoPath forms service, they
>> > request this via a support ticket.
>>
>> > We now have the requirement to provide a dedicated service to a
>> > specific customer who wants to be able to use Central Admin. The
>> > problem as I see it is that the dedicated service is in our hosting AD
>> > domain and therefore they could cause problems and also probably
>> > browse our AD (?)
>>
>> > Is there a way,apart from creating them in their own domain, that we
>> > can stop them interogating our hosting AD?
>>
>> > What are the real risks if we let them lose with central admin on a
>> > MOSS server in our hosting domain.
>>
>> > Any thoughts and advice would be most welcome.
>>
>> > Thanks
>>
>> > Andy- Hide quoted text -
>>
>> - Show quoted text -
>
> Hi John
> Thanks for your input. I think this is the stance that we are going to
> take. However I have seen other companies that offer full central
> admin access so I was also curious to how they did this. I guess they
> deployed a seperate AD forest specifically for that customer, or is
> there someway this can be done using forms based authentication and
> SQL server as the accounts repository?
> Thanks
> Andy
>
date: Tue, 8 Jul 2008 12:58:56 +1000   author:   SamS

Google
 
Web ureader.com


    COPYRIGHT 2007, YARDI TECHNOLOGY LIMITED, ALL RIGHT RESERVE  |   contact us