I did one better. I simply emailed the man himself. I relied heavily on those
chapters in the original installation. For some reason, I never thought the client
would decide to move the development environment onto the same box as production. I
suspect that the problem is actually the architecture somewhere, although I was
careful not to use application variables for any of the security stuff... I'll let
the list know what Daddy Ben says (if anything)... ;-)
Thanks for the input, Dave. And to the rest of the list, let this be a lesson to you.
Do *not* implement Advanced Security in kooky configurations using CFServer 4.5. It
may cause you some headaches that a custom security system using some COM integration
would allow you to avoid... :-o
<amusement>
And since I'm keeping track, I just wanted the list to know that Dave's last message
allowed him to attain the rank of Senior Spammer (a promotion from Associate Spammer).
As far as I know, the only Principal Spammer on the list is Billy... ;-)
</amusement>
On Tue, 21 August 2001, Dave Cahall wrote:
>
> I was relying on Ben Forta's Advanced Book - Chapter 7 & 8........looking at
> the examples on Pages 99 & 109 (Figures (7.10 and 8,9) but I honestly have
> not done this myself.
>
> 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 12:55 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Advanced Security quandry...
>
>
> 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
>
> -------------------------------------------------------------------------
> 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
