Hrm... I tend to disagree at this point. Policies are basically the application of
rules against users. Remember that any user associated with a policy has to be a
member of a User Directory associated with the context to begin with. You can't have
a policy applied to a user that isn't a part of the User Directory(s). On further
inspection, I've discovered that the only difference between development and
production is that development has additional rules and policies that don't exist in
the production environment. As such, development is more comprehensive and granular;
however, for the most part (and for anything that matters at login), the Rules,
Policies, and User Directories are the same. The only difference is the context name
itself.
Besides, we are only applying Advanced Security to UserObjects. For us, Rules and
Policies are only checked when IsAuthorized is invoked. The failure happens at simple
authentication, before IsAuthorized is ever called. The research I've done indicates
that <cfauthenticate> checks to see if the user and password are valid against *any
User Directory* associated with the specified context, regardless of Rules or Policies.
I've been banging my head against the wall with this for a few hours now. The only
solace I have right now is that I'm getting paid for it... ;-) Anyone else have any
ideas? Ben? :-D
On Tue, 21 August 2001, Dave Cahall wrote:
>
> From what I read, I think that is exactly your problem. Although you are
> using the same UserDirectory, the Policy can define a different set of users
> for each Context. As I understand it, you need to identify which users have
> access under each Policy. Therefore, users might be identified in one
> context but not the other. Therefore, when they try to log on, it checks
> the policy to see which users are defined. Meaning (if I understand it)
> that just because they are identified in the UserDirectory, that does not
> mean they will be authenticated. The Rule then determines who (of those who
> are authenticated) is authorized to perform a task.
>
> I may be way off base here but that is my understanding.
>
> Dave Cahall
> Vice President, Professional Services
> Digitaris Technologies, Inc.
> Office: 972.690.4131 ext 116
> Mobil: 214.914.9947
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 21, 2001 11:57 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Advanced Security quandry...
>
>
> Not a dumb question at all! =-) The only differences between the contexts
> have to do with Rules and Policies. In the development environment, the
> rules and policies that govern access can be monkeyed with, while in
> production they're pretty set.
>
> I wouldn't think that the Rules or Policies differences are the problem,
> since the thing fails at authentication. Does <cfauthenticate> look at
> anything except the User Directories associated with the referenced context,
> username and password? And why the heck would it fail with one context and
> not with the other when the User Directories associated with each are the
> same?
>
> On Tue, 21 August 2001, Dave Cahall wrote:
>
> >
> > This may be a dumb question but what is different in the two contexts?
> >
> > Dave Cahall
> > Vice President, Professional Services
> > Digitaris Technologies, Inc.
> > Office: 972.690.4131 ext 116
> > Mobil: 214.914.9947
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 21, 2001 6:15 AM
> > To: [EMAIL PROTECTED]
> > Subject: Advanced Security quandry...
> >
> >
> > Y'all are gonna love this one! ;-)
> >
> > I've got a client with two applications running on the same CF Server
> (4.5).
> > Let's call the applications DEV and PROD. The user is taking advantage of
> > CF Advanced Security to handle user authentication against an NT domain
> when
> > the users log into either application. There are separate security
> contexts
> > for each application (CONTEXT_DEV and CONTEXT_PROD). Both contexts use
> the
> > same User Directories to authenticate users against.
> >
> > So here's the dilema. The authentication is working fine for the DEV
> > application. The user logs in using NTLoginID and NTPassword,
> > authenticating against the CONTEXT_DEV context. However, when I use the
> > same code set for the PROD application, the <cfauthenticate> fails every
> > time. The only difference in the code set is the application name and the
> > security context name. Unfortunately, I can't get any useful information
> > from the failure. Has anyone else encountered a problem like this? Does
> > anyone know of a good way to debug this kind of issue?
> >
> > Perplexed,
> >
> > IronFury
> >
> >
> >
> > -------------------------------------------------------------------------
> > This email server is running an evaluation copy of the MailShield anti-
> > spam software. Please contact your email administrator if you have any
> > questions about this message. MailShield product info: www.mailshield.com
> >
> > -----------------------------------------------
> > To post, send email to [EMAIL PROTECTED]
> > To subscribe / unsubscribe: http://www.dfwcfug.org
> >
> > -------------------------------------------------------------------------
> > This email server is running an evaluation copy of the MailShield anti-
> > spam software. Please contact your email administrator if you have any
> > questions about this message. MailShield product info: www.mailshield.com
> >
> > -----------------------------------------------
> > To post, send email to [EMAIL PROTECTED]
> > To subscribe / unsubscribe: http://www.dfwcfug.org
>
>
>
> -------------------------------------------------------------------------
> This email server is running an evaluation copy of the MailShield anti-
> spam software. Please contact your email administrator if you have any
> questions about this message. MailShield product info: www.mailshield.com
>
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org
>
> -------------------------------------------------------------------------
> This email server is running an evaluation copy of the MailShield anti-
> spam software. Please contact your email administrator if you have any
> questions about this message. MailShield product info: www.mailshield.com
>
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org
-------------------------------------------------------------------------
This email server is running an evaluation copy of the MailShield anti-
spam software. Please contact your email administrator if you have any
questions about this message. MailShield product info: www.mailshield.com
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
