Does the app pool that runs the LLAWP process need to have admin rights on the Windows server ?
We are facing a problem where we installed the siteminder agent with an admin user .
When user is part of administrators group on windows , forms login is working fine.
But when we remove that user from the admin';s group and then try to access we get error "failed to encrypt agent name" in agent trace logs, i disabled encryptagentname so it went to the form login page but after that upon entering credentials on the login pageit returns in trace log with a message "[CSmHttpPlugin::ProcessSessionCookie][Unable to decode SMSESSSION cookie"
I have tried multiple options , re-register the agent, point to a single policy server,Granted the app pool permission to webagent directories, checked permission to file systems using proc mon , granted permission to the domain user associated with AppPool to IIS_USRS but no success.
As soon as i turn back admin permissions , it starts working. i,.e. i am able to login using form auth scheme.
has any one seen such issue.
Anybody able to assist further with this users question?
Well It is always advisable to run LLAWP process as an administrator, not because of SiteMinder 's restrictions but also because of Microsoft windows's restrictions, they have changed in windows 2008 R2 server.
If you see the security context attribute of windows 2008 server, they have changed many attributes with respect to shared memory access, semaphores and mutex. LLAWP also deals with these system resources.
I am not sure about the unable to decode SESSION cookie error, The only reason I can think of is, your worker process which starts the LLAWP process might not have permissions to read the SESSION cookie and hanced it throws the error.
Though we have not faced any such issue but sometimes we use to get the error about "not having write permissions on config files". Anyways I don't think there is any harm in running the LLAWP process as an administrator.
Thanks for the reply sandeep , problem is our corp policy is governing to move away from root access on window's server , hence the problem