Re: Incoming E-mail configuration - what permissions are required for what accounts?
- From: bradenm@xxxxxxxxx
- Date: Wed, 7 May 2008 15:21:03 -0700 (PDT)
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...@xxxxxxxxx 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...@xxxxxxxxxxxxxxxxxxx> 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...@xxxxxxxxx> wrote in message
news:4df85f7f-0927-41b8-b593-84c32b758e31@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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...@xxxxxxxxx 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?
.
- References:
- Incoming E-mail configuration - what permissions are required for what accounts?
- From: bradenm
- Re: Incoming E-mail configuration - what permissions are required for what accounts?
- From: spconsultant
- Re: Incoming E-mail configuration - what permissions are required for what accounts?
- From: callahan
- Re: Incoming E-mail configuration - what permissions are required for what accounts?
- From: bradenm
- Incoming E-mail configuration - what permissions are required for what accounts?
- Prev by Date: Re: Password Protected Folder
- Next by Date: DEPLOY PROJECT SERVER 2003 with MOSS 2007
- Previous by thread: Re: Incoming E-mail configuration - what permissions are required for what accounts?
- Next by thread: The machine key problem while using FBA
- Index(es):
Relevant Pages
|
