Hello Everybody,

I'm going to migrate a Site Server 3.0 site to a CS2002 site. I want
to implement proxy accounts to replace the old P&M. Does anybody have
impressions or opinions on implementing it this way?

Brian

[ Post a follow-up to this message ]

Hi Brian,

Idepends on exactly why you need a proxy account. You can have proxy account
s in CS2002 - look in the CS docs for "proxy accounts", however this wont ha
ve the exact same result as the site server technique.

In site server a proxy account was need because users/groups were stored in 
SQL/LDAP and you can only grant NTFS file permissions to NT/Active Direcory 
users. Therefore if created a NT/AD impersonation(proxy) account, the SQL/LD
AP user could then "run as" the impersonation account.

Below is a high level overview on how the Site Server authentication service
 and ISAPI filter work in regards to a impersonation account. Compare this t
o how the Commerce Server ISAPI filter works in conjunction with Active Dire
ctory. There is a lot of reading below, but hopefully it helps.

Commerce Server AuthFilter
1.. User requests a restricted page i.e. IIS anonymous access is not allowed
 on the file requested - at this point usually an end user would get a basic
 clear text dialog popup. 
2.. User doesn't have CS Auth Ticket, the CS ISAPI filter redirects the user a login pa
ge (path to this page is setup in the Commerce Server Manager in the "CS Authentication
" global resource). This page can be on a dedicated web server that is not the same as 
the server that holds the requested page. For this the config path must be set to a ful
ly qualified path e.g. http://login.lexisnexis.co.uk/auth/login.asp. The ISA
PI filter adds a cookie (called MSCSFirstRequestedURL) during the redirect; 
it contains the fully qualified URL of the requested page so that the login 
page knows where to direct the user after a successful login. 
3.. The user will enter a username and password into the login page and subm
it it. Code will need to be created to check the username and password again
st AD. If the correct credentials have been supplied a CS Auth Ticket should
 be issued using the AuthManager.SetAuthTicket method, this will issue an au
thentication session cookie to the user. The encrypted cookie will contain a
 username, timestamp and time to live (TTL - used for expiration). The user 
should then be redirected back to original requested page (using the value f
rom the MSCSFirstRequestedURL cookie). Included on the URL to original page 
MUST be query string (in a specific format) containing the user's username a
nd password. The CS ISAPI filter uses these values to pass to IIS. Example q
uery string is "?&proxyuser=domainname\administrator&proxypwd=password". The
 username and password can also be sent to the requested page using an HTTP 
POST rather that a GET. A sample login.asp page is included with all CS samp
le sites. 
4.. The CS ISAPI filter SF_NOTIFY_AUTHENTICATION event fires just before IIS
 authenticates a user, and it is at this point that the CS ISAPI filter pass
es the username and password to IIS. This prevents the end user being prompt
ed with a pop-up dialog box asking for credentials. The CS ISAPI filter cach
es the user's password in memory. On subsequent page requests the CS Auth Ti
cket is used to get the user's username, and the password is looked up in th
e cache, if both are present the ISAPI filter can pass them to IIS to preven
t the pop-up dialog box asking for credentials. If the CS Auth Ticket is not
 present, has expired or the user's password is not in the cache, the user i
s re-directed to the login page (as in step 2). It must be noted that the CS
 ISAPI filter also removes the query string from the URL so that the user do
esn't see his/her credentials on the URL. 
5.. There are a couple of techniques that can be used to prevent users that 
have been load balanced across CS web servers from being delivered the login
 page asking for credentials because the user has hit a web server that does
n't have his/her password cached. 
6.. Use sticky sessions to ensure the user always returns to the same web se
rver 
7.. Code the login page to maintain a password cache (this could be in memor
y, or some other store e.g. SQL). When a user is directed to the login page 
and the user has a valid CS Auth Ticket, check to see if his/her password is
 in the cache. If it is redirect the user back to the requested page with th
e appropriate query string, else display the login page. This will force the
 ISAPI filter to cache the user's password. 
So as you can see, you can create a impersonation account and this accounts 
details must be passed to the CS ISAPI filter. This account must be an AD ac
count.

Site Server Authentication

There are several differences in the way the Site Server ISAPI filter and Co
mmerce Server 2002 ISAPI filters work. Below is a high level overview of how
 the Site Server authorization mechanism works in terms of using NTFS permis
sions to grant/deny access to users.

Users and groups in the Membership Directory cannot be placed directly in Wi
ndows ACLs, but they can be mapped to Windows NT/AD groups, which are used i
n ACLs to protect applications and content. When your site uses Membership A
uthentication mode, for each group created in the Membership Directory, each
 Site Server Authentication Service automatically creates on its respective 
server computer a corresponding Windows group. A Membership Directory group 
called groupname would be mapped to a Windows group called SiteSrv_directory
name groupname, including any group nesting. Here are two examples: 

·         A group cn=toys, ou=groups, o=acme would be mapped to the group Si
te_acme_toys. 

·         A group cn=toys, ou=manufacturers, ou=groups, o=acme would be mapp
ed to the group Site_acme_manufacturers_toys. 

 

Note

·         Local or Domain global groups can be used.

At the most basic level, the user is represented by an account in the Member
ship Directory. The user is assigned to groups in the Membership Directory t
hat correspond to the content that the user is authorized to access.

This authorization information needs to be made available to the application
s to which the client would connect. To accomplish this, P&M automatically c
reates a special Windows NT Server user account, the Impersonation Account (
with the name MemProxyUser_n), for every Membership Server instance that is 
used for authentication. Every user who is authenticated is logged on to the
 application server as an instance of its corresponding Impersonation Accoun
t.

For each instance of the Impersonation Account, a unique Windows security co
ntext is created, which corresponds to the current user's permissions in the
 Membership Directory. As part of authentication, the Site Server Authentica
tion Service interrogates the Membership Directory to determine all the grou
ps and subgroups the user belongs to. When the Impersonation Account instanc
e is logged on, the corresponding (mapped) Windows user groups are attached 
to the security context of the Impersonation Account instance, thereby givin
g the Impersonation Account the effect of the same group memberships as the 
user has in the Membership Directory. This Site Server Authentication Servic
e communicates to the P&M store on behalf of the ISAPI filter. The security 
context is created as a standard Windows security token containing the Secur
ity IDs (SIDs) of the Impersonation Account and all Windows groups which map
 to groups that the user belongs to in the Membership Directory. It is this 
token that the ISAPI filter passes to IIS to enforce the correct security co
ntext.

As a result any resources requested through IIS will use the security contex
t of the impersonation account and the associated groups for that session.

The Commerce Server ISAPI filter doesn't work in this way at all. The Commer
ce Server ISAPI filter uses a Windows username and password passed on a quer
y string to create a security context. Hence all resources request through I
IS will use the security context of the username passed on the query string,
 and its associated group permissions. This user must be a Windows user (loc
al computer account or AD account).


Hope this helps,
Michael

-- 
This posting is provided "AS IS" with no warranties, and confers no rights.
"Brian Fung" <bfung25@hotmail.com> wrote in message news:e0d644.0402200754.53ad7a78@posting
.google.com...
> Hello Everybody,
> 
> I'm going to migrate a Site Server 3.0 site to a CS2002 site. I want
> to implement proxy accounts to replace the old P&M. Does anybody have
> impressions or opinions on implementing it this way?
> 
> Brian

[ Post a follow-up to this message ]

Thanks for the response Micheal. That really helped a lot.
My question to you is how secure is it to user the Response.redirect
and having the UserID and PASWORD in the querystring? Isn't that a
security risk? It not, then why?

Brian


"Michael O'Donovan [MSFT]" <michodon@online.microsoft.com> wrote in message news:<u$vi$
T8#DHA.1036@TK2MSFTNGP10.phx.gbl>...
> Hi Brian,
>
> Idepends on exactly why you need a proxy account. You can have proxy
> accounts in CS2002 - look in the CS docs for "proxy accounts", however
> this wont have the exact same result as the site server technique.
>
> In site server a proxy account was need because users/groups were stored
> in SQL/LDAP and you can only grant NTFS file permissions to NT/Active
> Direcory users. Therefore if created a NT/AD impersonation(proxy)
> account, the SQL/LDAP user could then "run as" the impersonation
> account.
>
> Below is a high level overview on how the Site Server authentication
> service and ISAPI filter work in regards to a impersonation account.
> Compare this to how the Commerce Server ISAPI filter works in
> conjunction with Active Directory. There is a lot of reading below, but
> hopefully it helps.
>
> Commerce Server AuthFilter
>   1.. User requests a restricted page i.e. IIS anonymous access is not
> allowed on the file requested - at this point usually an end user would
> get a basic clear text dialog popup.
>   2.. User doesn't have CS Auth Ticket, the CS ISAPI filter redirects
> the user a login page (path to this page is setup in the Commerce Server
> Manager in the "CS Authentication" global resource). This page can be on
> a dedicated web server that is not the same as the server that holds the
> requested page. For this the config path must be set to a fully
> qualified path e.g. http://login.lexisnexis.co.uk/auth/login.asp. The
> ISAPI filter adds a cookie (called MSCSFirstRequestedURL) during the
> redirect; it contains the fully qualified URL of the requested page so
> that the login page knows where to direct the user after a successful
> login.
>   3.. The user will enter a username and password into the login page
> and submit it. Code will need to be created to check the username and
> password against AD. If the correct credentials have been supplied a CS
> Auth Ticket should be issued using the AuthManager.SetAuthTicket method,
> this will issue an authentication session cookie to the user. The
> encrypted cookie will contain a username, timestamp and time to live
> (TTL - used for expiration). The user should then be redirected back to
> original requested page (using the value from the MSCSFirstRequestedURL
> cookie). Included on the URL to original page MUST be query string (in a
> specific format) containing the user's username and password. The CS
> ISAPI filter uses these values to pass to IIS. Example query string is
> "?&proxyuser=domainname\administrator&proxypwd=password". The
> username and password can also be sent to the requested page using an
> HTTP POST rather that a GET. A sample login.asp page is included with
> all CS sample sites.
>   4.. The CS ISAPI filter SF NOTIFY AUTHENTICATION event fires just
> before IIS authenticates a user, and it is at this point that the CS
> ISAPI filter passes the username and password to IIS. This prevents the
> end user being prompted with a pop-up dialog box asking for credentials.
> The CS ISAPI filter caches the user's password in memory. On subsequent
> page requests the CS Auth Ticket is used to get the user's username, and
> the password is looked up in the cache, if both are present the ISAPI
> filter can pass them to IIS to prevent the pop-up dialog box asking for
> credentials. If the CS Auth Ticket is not present, has expired or the
> user's password is not in the cache, the user is re-directed to the
> login page (as in step 2). It must be noted that the CS ISAPI filter
> also removes the query string from the URL so that the user doesn't see
> his/her credentials on the URL.
>   5.. There are a couple of techniques that can be used to prevent users
> that have been load balanced across CS web servers from being delivered
> the login page asking for credentials because the user has hit a web
> server that doesn't have his/her password cached.
>   6.. Use sticky sessions to ensure the user always returns to the same
> web server
>   7.. Code the login page to maintain a password cache (this could be in
> memory, or some other store e.g. SQL). When a user is directed to the
> login page and the user has a valid CS Auth Ticket, check to see if
> his/her password is in the cache. If it is redirect the user back to the
> requested page with the appropriate query string, else display the login
> page. This will force the ISAPI filter to cache the user's password.
> So as you can see, you can create a impersonation account and this
> accounts details must be passed to the CS ISAPI filter. This account
> must be an AD account.
>
> Site Server Authentication
>
> There are several differences in the way the Site Server ISAPI filter
> and Commerce Server 2002 ISAPI filters work. Below is a high level
> overview of how the Site Server authorization mechanism works in terms
> of using NTFS permissions to grant/deny access to users.
>
> Users and groups in the Membership Directory cannot be placed directly
> in Windows ACLs, but they can be mapped to Windows NT/AD groups, which
> are used in ACLs to protect applications and content. When your site
> uses Membership Authentication mode, for each group created in the
> Membership Directory, each Site Server Authentication Service
> automatically creates on its respective server computer a corresponding
> Windows group. A Membership Directory group called groupname would be
> mapped to a Windows group called SiteSrv directoryname groupname,
> including any group nesting. Here are two examples:
>
>           A group cn=toys, ou=groups, o=acme would be mapped to
> the group Site acme toys.
>
>           A group cn=toys, ou=manufacturers, ou=groups, o=acme
> would be mapped to the group Site acme manufacturers toys.
>
>
>
> Note
>
>           Local or Domain global groups can be used.
>
> At the most basic level, the user is represented by an account in the
> Membership Directory. The user is assigned to groups in the Membership
> Directory that correspond to the content that the user is authorized to
> access.
>
> This authorization information needs to be made available to the
> applications to which the client would connect. To accomplish this, P&M
> automatically creates a special Windows NT Server user account, the
> Impersonation Account (with the name MemProxyUser n), for every
> Membership Server instance that is used for authentication. Every user
> who is authenticated is logged on to the application server as an
> instance of its corresponding Impersonation Account.
>
> For each instance of the Impersonation Account, a unique Windows
> security context is created, which corresponds to the current user's
> permissions in the Membership Directory. As part of authentication, the
> Site Server Authentication Service interrogates the Membership Directory
> to determine all the groups and subgroups the user belongs to. When the
> Impersonation Account instance is logged on, the corresponding (mapped)
> Windows user groups are attached to the security context of the
> Impersonation Account instance, thereby giving the Impersonation Account
> the effect of the same group memberships as the user has in the
> Membership Directory. This Site Server Authentication Service
> communicates to the P&M store on behalf of the ISAPI filter. The
> security context is created as a standard Windows security token
> containing the Security IDs (SIDs) of the Impersonation Account and all
> Windows groups which map to groups that the user belongs to in the
> Membership Directory. It is this token that the ISAPI filter passes to
> IIS to enforce the correct security context.
>
> As a result any resources requested through IIS will use the security
> context of the impersonation account and the associated groups for that
> session.
>
> The Commerce Server ISAPI filter doesn't work in this way at all. The
> Commerce Server ISAPI filter uses a Windows username and password passed
> on a query string to create a security context. Hence all resources
> request through IIS will use the security context of the username passed
> on the query string, and its associated group permissions. This user
> must be a Windows user (local computer account or AD account).
>
>
> Hope this helps,
> Michael
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "Brian Fung" <bfung25@hotmail.com> wrote in message
> news:e0d644.0402200754.53ad7a78@posting.google.com... 
> --

[ Post a follow-up to this message ]

Hi Brian,

I would assume that you would run SSL across an authenticated session and
hence this would be the same as a user typing in a username and password in
a login page. Also you don't have to put it on the query string you can do a
form post. Check the CS docs for more information.

Hope this helps,
Michael

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Brian Fung" <bfung25@hotmail.com> wrote in message
news:e0d644.0402261711.74e54210@posting.google.com...
> Thanks for the response Micheal. That really helped a lot.
> My question to you is how secure is it to user the Response.redirect
> and having the UserID and PASWORD in the querystring? Isn't that a
> security risk? It not, then why?
>
> Brian
>
>
> "Michael O'Donovan [MSFT]" <michodon@online.microsoft.com> wrote in
message news:<u$vi$T8#DHA.1036@TK2MSFTNGP10.phx.gbl>... 
 

[ Post a follow-up to this message ]