Within a console application, I'm get an error using any of the CmsApplicati
onContext.AuthenticateAs& #91;CurrentUser|User|Guest|UsingUserHand
le]
unless the user that's logged in is a member of the local machine's Administ
rators
group.

The exception thrown:
CmsAccessDeniedException: The windows credentials could not be validated.

Once the user is added ot the local admins group, everything works fine.
The user's AD account is listed as an Administrator within the CMS app (via
Site Manager). This happens on more than one box (developer machines, shared
build server [dev & build machines all share same CMS repository], autho
ring
& production servers [using a shared respository]). All machines are in 
the
same domain as the user.

While this console app should only be run by admins, and having them added
to the admins group on the local box isn't a huge deal and can be temporary,
it's still nagging at me

After scouring the group and Stefan's FAQ, decided to post here as a result.
Ideas?

--
-AC [MVP MCMS]
http://www.andrewconnell.com
http://www.andrewconnell.com/mvp

[ Post a follow-up to this message ]

Hi AC!

Can you confirm that by "the user that's logged in" you mean the mean the
user whom is interactively logged on at the console rather than the user
account you are using with AuthenticateAs?

If so, the problem here is nothing to do with MCMS - it's the inability of
the process identity of the application (in this case of a console app or
winform - the interactive user account) to validate credentials in AD (or
the local SAM for that matter).

The suberror message indicates the problem - changing the AuthenticateAs
won't make any difference as it will never be able to authenticate!!

This is due to a default policy change in XP SP2 and W2K3 - you need to give
the interactive user the "Impersonate a client after authentication" local
user right assignment either via Local Security Policy or Group Policy.
Better yet - create a group in AD for those who need to use these types of
apps.

By default this user right is only assigned to Admins, ASPNET and SERVICE.
The reason it doesn't get caught often is most people still run on thier box
as Admins... tsk tsk... 
Anything which uses CmsApplicationContext needs this right. Without the
right the request for authentication takes place with a NULL session and
fails miserably.

hth
Spence
www.mcmsfaq.com



"AC [MVP MCMS]" <swamplander@gmail.com> wrote in message
 news:3a9a4f4d6aa7f8c7eca06979e3f2@msnews
.microsoft.com...
> Within a console application, I'm get an error using any of the
> CmsApplicationContext.AuthenticateAs[CurrentUser|User|Guest|UsingUserH
andle]
> unless the user that's logged in is a member of the local machine's
> Administrators group.
>
> The exception thrown:
> CmsAccessDeniedException: The windows credentials could not be validated.
>
> Once the user is added ot the local admins group, everything works fine.
> The user's AD account is listed as an Administrator within the CMS app
> (via Site Manager). This happens on more than one box (developer machines,
> shared build server [dev & build machines all share same CMS repositor
y],
> authoring & production servers [using a shared respository]). All mach
ines
> are in the same domain as the user.
>
> While this console app should only be run by admins, and having them added
> to the admins group on the local box isn't a huge deal and can be
> temporary, it's still nagging at me
> After scouring the group and Stefan's FAQ, decided to post here as a
> result. Ideas?
>
> --
> -AC [MVP MCMS]
> http://www.andrewconnell.com
> http://www.andrewconnell.com/mvp
>
>

[ Post a follow-up to this message ]

Hey Spence!

Thanks for the reply... now I don't feel so bad beating my head against the
wall... appears this is coming down to an OS policy issue and not with CMS..
.

I believe I didn't state the exact situation which [I think] mitigates t
he
rest of your post.  First, I wasn't aware of the policy change so at the
very least, your reply did help . With that being said, let me clarify
the situation... what you explained though does sound like the behavior.

Here's the deal: I have a console app that authenticates the current user
(when that failed I tried using the AuthenticateUsingUserHandle) to get the
CmsApplicationContext (what the console app does isn't important at this
time as the error is thrown on the authentication line... it never makes
it past that point). The console app ~usually~ runs on one of our servers
(shared build, dev, QA, authoring... usually not on production). To run it,
people login using Remote Desktop and execute the app.

Interactive login does mean logging in at the console... so it seems that
the Remote Desktop session is not (due to the policy you outlined) playing
by the same rules and thus, the console app won't run.

You have any suggestions how I can set it so the person who's logging in
(via Remote Desktop) can simply get a CmsApplicationContext using their own
credentials?

If not...the only way around this issue is:
> add the user to the admin group
> specify the user (or AD group) who has the "Impersonate A Client After
Authentication" permission

Frustrated,
-AC

--
-AC [MVP MCMS]
http://www.andrewconnell.com
http://www.andrewconnell.com/mvp
[vbcol=seagreen]
> Hi AC!
>
> Can you confirm that by "the user that's logged in" you mean the mean
> the user whom is interactively logged on at the console rather than
> the user account you are using with AuthenticateAs?
>
> If so, the problem here is nothing to do with MCMS - it's the
> inability of the process identity of the application (in this case of
> a console app or winform - the interactive user account) to validate
> credentials in AD (or the local SAM for that matter).
>
> The suberror message indicates the problem - changing the
> AuthenticateAs won't make any difference as it will never be able to
> authenticate!!
>
> This is due to a default policy change in XP SP2 and W2K3 - you need
> to give the interactive user the "Impersonate a client after
> authentication" local user right assignment either via Local Security
> Policy or Group Policy. Better yet - create a group in AD for those
> who need to use these types of apps.
>
> By default this user right is only assigned to Admins, ASPNET and
> SERVICE.
> The reason it doesn't get caught often is most people still run on
> thier box
> as Admins... tsk tsk... 
> Anything which uses CmsApplicationContext needs this right. Without
> the
> right the request for authentication takes place with a NULL session
> and
> fails miserably.
> hth
> Spence
> www.mcmsfaq.com
> "AC [MVP MCMS]" <swamplander@gmail.com> wrote in message
>  news:3a9a4f4d6aa7f8c7eca06979e3f2@msnews
.microsoft.com...
> 

[ Post a follow-up to this message ]

Hey AC!

A logon via remote desktop == an interactive logon.
(Whilst that's only 98% true, in the context of this problem the other 2%
just confuse the issue!)

There's no way to get a CmsAppContext without the "Impersonate A Client Afte
r
Authentication" assignment.

But this is no biggie if you own the boxes. - remember ASPNET has this assig
nment
so it's a question of trust (in the deployed code).
Just create a group which contains the users you need to be able to run the
app and then give that group the assignment.

Then you're good to go. It'll work at the console - via remote desktop -
via runas..., whatever.

If you already have a group in your Site Mangler Admins Role group - u could
give that group the assignment.

you can test this on a local box - create a regular user and add it to MCMS
admins in Site Mangler. use Run As... to run the app as the regular user
and watch it fail at AuthenticateAs until you grant the assignment. (you'll
probably get a few CMS licence has expired errrors on the inital call as
well - but let's not go there )


s.



[vbcol=seagreen]
> Hey Spence!
>
> Thanks for the reply... now I don't feel so bad beating my head
> against the wall... appears this is coming down to an OS policy issue
> and not with CMS...
>
> I believe I didn't state the exact situation which [I think] mitigates
> the rest of your post.  First, I wasn't aware of the policy change so
> at the very least, your reply did help . With that being said, let
> me clarify the situation... what you explained though does sound like
> the behavior.
>
> Here's the deal: I have a console app that authenticates the current
> user (when that failed I tried using the AuthenticateUsingUserHandle)
> to get the CmsApplicationContext (what the console app does isn't
> important at this time as the error is thrown on the authentication
> line... it never makes it past that point). The console app ~usually~
> runs on one of our servers (shared build, dev, QA, authoring...
> usually not on production). To run it, people login using Remote
> Desktop and execute the app.
>
> Interactive login does mean logging in at the console... so it seems
> that the Remote Desktop session is not (due to the policy you
> outlined) playing by the same rules and thus, the console app won't
> run.
>
> You have any suggestions how I can set it so the person who's logging
> in (via Remote Desktop) can simply get a CmsApplicationContext using
> their own credentials?
>
> If not...the only way around this issue is:
> 
> Authentication" permission
>
> Frustrated,
> -AC 

[ Post a follow-up to this message ]

Hello Spencer Harbar [MVP],

Well well well... sure enough that's the problem! It's not how your logged
in, it's how your account is setup. I was racking my brain thinking "I've
never seen something in CMS that would affect this!

Thanks Spence!

--
-AC [MVP MCMS]
http://www.andrewconnell.com
http://www.andrewconnell.com/mvp
[vbcol=seagreen]
> Hey AC!
>
> A logon via remote desktop == an interactive logon.
> (Whilst that's only 98% true, in the context of this problem the other
> 2%
> just confuse the issue!)
> There's no way to get a CmsAppContext without the "Impersonate A
> Client After Authentication" assignment.
>
> But this is no biggie if you own the boxes. - remember ASPNET has this
> assignment
> so it's a question of trust (in the deployed code).
> Just create a group which contains the users you need to be able to
> run the
> app and then give that group the assignment.
> Then you're good to go. It'll work at the console - via remote desktop
> - via runas..., whatever.
>
> If you already have a group in your Site Mangler Admins Role group - u
> could give that group the assignment.
>
> you can test this on a local box - create a regular user and add it to
> MCMS admins in Site Mangler. use Run As... to run the app as the
> regular user and watch it fail at AuthenticateAs until you grant the
> assignment. (you'll probably get a few CMS licence has expired errrors
> on the inital call as well - but let's not go there )
>
> s.
> 

[ Post a follow-up to this message ]