bradenm
Wed May 07 17:21:03 CDT 2008
After a bunch of hunting, I think I may have the culprit. However,
I'm not sure where to go to play with permissions to make it right.
I am getting occasional Audit Failures in the Security log on the MOSS
server. The "Task Category" is "Other Object Access Events."
My curiosity was piqued because the Security ID involved is the domain
account used by the Web App I have been testing with. (svcmoss_ap2,
in this case.)
Here's the full text of the event from our 2k8 log:
====8<=====
A handle to an object was requested.
Subject:
Security ID: SHG\svcmoss_ap2
Account Name: SvcMOSS_ap2
Account Domain: SHG
Logon ID: 0x15a95299
Object:
Object Server: SC Manager
Object Type: SERVICE OBJECT
Object Name: WinHttpAutoProxySvc
Handle ID: 0x0
Process Information:
Process ID: 0x280
Process Name: C:\Windows\System32\services.exe
Access Request Information:
Transaction ID: {00000000-0000-0000-0000-000000000000}
Accesses: Query status of service
Start the service
Query information from service
Access Mask: 0x94
Privileges Used for Access Check: -
Restricted SID Count: 0
=====>8======
Usually there are three or four of these in rapid succession, and the
"Accesses" vary on each one, but usually "query status" and "query
information" are involved. They're also asking about several
different "Object Name:" - ServicesActive, WinHttpAutoProxySvc, and
CryptSvc are the ones it cares about.
I did some digging in the MSDN documentation for SC (the service
controller) and its permissions, this is the information about rights
on services:
http://msdn.microsoft.com/en-us/library/ms685981(VS.85).aspx
At this point I'm in over my head, but I figured I'd throw it out in
case it helps someone else...
On May 6, 11:09 pm, brad...@gmail.com wrote:
> Callahan -
>
> So this is "known" behavior with MOSS 07/WSS 3? It's pretty sad. The
> most frustrating part is that NO logs give any information about
> it. :/
>
> Unfortunately, our users aren't clueful enough to handle it without
> DMS, so I will have to make our app pools local admin. The only good
> point is that this is internal-use only, so security shouldn't be too
> big of a concern... but I'm still annoyed.
>
> Thanks,
> Braden
>
> Unfortunately, our users aren't smart enough to figure things out
> On May 5, 12:23 pm, "callahan" <cacalla...@NOSPAM.computer.org> wrote:
>
> > LOL. Spconsultant, I think you missed the point. The OP is using DIRECTORY
> > MANAGEMENT SERVICES. It's because of DMS that he needs the app pools to be
> > local administrators.
>
> > Of course we all had tohaveour install account be a local administrator
> > when installing SharePoint. If we didn't, it wouldn't install. ; ) The OP
> > was very straightforward about their use of least privilege, they wouldn't
> > give any account administrative rights to their servers if they didn't need
> > to. They also had the standard issues we've all had when dealing with
> > permissions and performance with DMS. They in no way mentioned DCOM errors
> > because those (usually caused by sharepoint not giving service accounts
> > local activation rights to IIS WAMREG admin service) aren't commonly what
> > cause DMS not to work.
>
> > If you arerunningDMS in yourenterprise, please give us explicit
> > information as to how you set your permissions, both for the farm account on
> > the OU, as well as the app pool accounts.
>
> > -callahan"spconsultant" <gfpilot2...@yahoo.com> wrote in message
>
> >news:4df85f7f-0927-41b8-b593-84c32b758e31@27g2000hsf.googlegroups.com...
> > Ihavenot discovered the "fact" that the web app pool accounts musthavelocal admin on all servers. Ihaveat least 5 Production installs
> > ofMOSS(Standard andEnterprise, with and without active use of excel
> > services and forms services) and at least another 5 of just WSS,runningon single servers single computer and multi computer Farm
> > environments, and in NONE of them are the App Pools members of any
> > administrator groups. (ALL Just regular domain user class accounts).
> > The FARM and SQL Services accounts are also NOT members of any admin
> > groups.
>
> > I use a seperate INSTALL account (used only for the initial setup
> > (configuration wizzard) that IS a member of local admin on allserver
> > component computers. There are extra steps to take to make this work,
> > which are well documented on many Blogs. (i.e. granitng local
> > activation to certain components). Of course making them local or
> > domain admins removes the need to do those extra steps (fine if it
> > doesn't really matter to you) but that is not a requirement in my
> > experience.
>
> > What specific errors do you get? If they are DCOM errors, just google
> > the event log text, and you will see how to find the component, and
> > how to grant local activation access.
>
> > On May 2, 5:12 pm, brad...@gmail.com wrote:
>
> > > Hello all,
>
> > > IhaveaMOSS2007SP1(x64)serverrunningonWindows2008Enterprise
> > > (x64).
>
> > > The system is configured using the Microsoft best practices forMOSS,
> > > which use the concept of "least privilege," creating several domain
> > > accounts thathaveonly standard user rights plus whateverMOSSauto-
> > > assigns to them.
>
> > > Ihavebeen fighting with the incoming e-mail stuff for a week. I'm
> > > aware of the whitepaper from "CombinedKnowledge" - I followed it
> > > closely, but continued tohaveproblems. Here's a layout of the
> > > environment.
>
> > > SQL 2000 SP4 on a two node Cluster (has to be SQL 2000 due to other
> > > app requirements)
> > > SHGMOSS1 - singleMOSS2007Enterpriseserver, all services are
> > > currentlyrunninghere.
>
> > > Domain is SHG and all accounts listed below are in that domain as
> > > normal users.
>
> > > Accounts used forMOSS:
>
> > > svcMOSS - Main farm account, Central Admin app pool and DB access
> > > svcMOSS_SSP - Shared Service Provider (SharedServices1) account
> > > svcMOSS_Index - DB index / search account
> > > svcMOSS_ca - content access account for indexer
> > > svcMOSS_ap1 - App Pool 1 account (app pool for SharedServices1)
> > > svcMOSS_ap2 - App pool 2 account (app pool for MySites)
>
> > > While trying to mail-enable a collection, I kept getting "Access
> > > denied" and "Error in application" type errors when it was trying to
> > > create the contact in Active Directory. My DirMan config looks like
> > > so:
>
> > > OU=SharePoint,DC=ourcompany,DC=local
> > > The OU "SharePoint" exists in the root of the domain, and
> > > "ourcompany.local" (obviously changed) is the FQDN for the domain.
>
> > > The documentation is NOT clear on what accounts need access to the
> > > OU. The CombinedKnowledge whitepaper implies that only the Central
> > > Admin account has to be able to modify the OU but Ihaveeventually
> > > found this to be FALSE. Out of frustration, I eventually gave *all*
> > > of the accounts listed above Full Access to the OU (and all child
> > > objects). I was still getting Access Denied and/or generic Errors. I
> > > haven't even bothered to setup the SMTP portion of things because the
> > > process is failing before it gets that far - the contact isn't being
> > > created in Active Directory.
>
> > > Note that all accounts are in the appropriate WSS_WPG and
> > > WSS_Admin_WPG groups on the local machine - I followed the normal
> > > setup procedure and allowed the system to do what it wanted when I
> > > chose the accounts.
>
> > > What finally "fixed" the problem - I had to make the App Pool account
> > > for any App Pool that I want to e-mail enable a LOCAL Administrator on
> > > theMOSSserver. This makes NO sense to me - why would I need local
> > > Admin for a domain operation? Also, I had the exact same problem when
> > > using "least privilege" accounts onWindows2003 R2 SP2, so this is
> > > not anythingServer2008specific. Ihavebeen using Process Monitor
> > > to figure out what is failing for a normal user account but i'm not
> > > getting any access denied or failure messages, so I'm not sure why the
> > > App Pool accountshaveto be Local Administrators for the contact
> > > creation to work.
>
> > > So, Ihavethings "working" but in a sub-optimal way due to the lack
> > > of security. Microsoft's documented practices don't work here, and
> > > there's no explanation as to why. Event Logs and theMOSSlogs
> > > haven't helped me yet. Can someone point out what security options I
> > > might need to get this to work without Administrator rights?