Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Directory (http://www.linux-archive.org/fedora-directory/)
-   -   Bind to consumer binds to provider as well (http://www.linux-archive.org/fedora-directory/451067-bind-consumer-binds-provider-well.html)

Gerrard Geldenhuis 11-11-2010 11:30 AM

Bind to consumer binds to provider as well
 
Hi
In our setup we have clients authenticating against a consumer server. The consumer server is chained to the provider server for writes and we have passwordpolicy configured including lockout settings. We replicate all password data.
*
When I do a bind to the consumer(slave) I also see a bind to the provider(master) this seems really silly. My understanding is that this behaviour is caused by needing to centrally store login attempts. I have raised this matter previously but just wanted to double check that the behaviour I am seeing is expected and not due to a misconfiguration on our part.
*
Best Regards


__________________________________________________ ______________________

In order to protect our email recipients, Betfair Group use SkyScan from

MessageLabs to scan all Incoming and Outgoing mail for viruses.



__________________________________________________ ______________________

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Rich Megginson 11-12-2010 03:33 PM

Bind to consumer binds to provider as well
 
Gerrard Geldenhuis wrote:
>
> Hi
>
> In our setup we have clients authenticating against a consumer server.
> The consumer server is chained to the provider server for writes and
> we have passwordpolicy configured including lockout settings. We
> replicate all password data.
>
>
>
> When I do a bind to the consumer(slave) I also see a bind to the
> provider(master) this seems really silly. My understanding is that
> this behaviour is caused by needing to centrally store login attempts.
> I have raised this matter previously but just wanted to double check
> that the behaviour I am seeing is expected and not due to a
> misconfiguration on our part.
>
Are you using Chain On Update for Binds?
http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
>
>
>
> Best Regards
>
>
> __________________________________________________ ______________________
> In order to protect our email recipients, Betfair Group use SkyScan from
> MessageLabs to scan all Incoming and Outgoing mail for viruses.
>
> __________________________________________________ ______________________
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Gerrard Geldenhuis 11-12-2010 04:22 PM

Bind to consumer binds to provider as well
 
> >
> > When I do a bind to the consumer(slave) I also see a bind to the
> > provider(master) this seems really silly. My understanding is that
> > this behaviour is caused by needing to centrally store login attempts.
> > I have raised this matter previously but just wanted to double check
> > that the behaviour I am seeing is expected and not due to a
> > misconfiguration on our part.
> >
> Are you using Chain On Update for Binds?
> http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
> >

We are indeed, we used that howto to set it up. Reading it now again it does say it will use the chaining backend for binds. Why is that? If we replicate changes down to the consumer how can the data be "fresher" than the consumer?

Regards

__________________________________________________ ______________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.

__________________________________________________ ______________________
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Rich Megginson 11-12-2010 04:36 PM

Bind to consumer binds to provider as well
 
Gerrard Geldenhuis wrote:
>>> When I do a bind to the consumer(slave) I also see a bind to the
>>> provider(master) this seems really silly. My understanding is that
>>> this behaviour is caused by needing to centrally store login attempts.
>>> I have raised this matter previously but just wanted to double check
>>> that the behaviour I am seeing is expected and not due to a
>>> misconfiguration on our part.
>>>
>>>
>> Are you using Chain On Update for Binds?
>> http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
>>
>
> We are indeed, we used that howto to set it up. Reading it now again it does say it will use the chaining backend for binds. Why is that?
In order to have global password policy. Let's say for example that you
have password policy which states accounts are locked out after 3
unsuccessful login attempts. If you have 5 directory servers, each with
local password policy, that effectively means an attacker has 15 tries
to guess the password instead of 3.
> If we replicate changes down to the consumer how can the data be "fresher" than the consumer?
>
If the password policy attributes are updated on the master(s) and
pushed to the consumer(s), they are all equally "fresh".
> Regards
>
> __________________________________________________ ______________________
> In order to protect our email recipients, Betfair Group use SkyScan from
> MessageLabs to scan all Incoming and Outgoing mail for viruses.
>
> __________________________________________________ ______________________
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Gerrard Geldenhuis 11-12-2010 05:13 PM

Bind to consumer binds to provider as well
 
> >>>
> >> Are you using Chain On Update for Binds?
> >> http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
> >>
> >
> > We are indeed, we used that howto to set it up. Reading it now again it
> does say it will use the chaining backend for binds. Why is that?

Why is that? I don't know .
According the the wiki http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
the consumer will use the chaining backend when I do bind/write requests.

I can understand why you would want to "centrally" manage login attempts but would it not better to handle login attempts locally on the consumer and then only if a login attempts fail and you need to do a write then write to the master. I can imagine though that with this approach you can potentially have more auth attempts than is allowed for.

> In order to have global password policy. Let's say for example that you have
> password policy which states accounts are locked out after 3 unsuccessful
> login attempts. If you have 5 directory servers, each with local password
> policy, that effectively means an attacker has 15 tries to guess the password
> instead of 3.
> > If we replicate changes down to the consumer how can the data be
> "fresher" than the consumer?

My sentence was less than ideal. If changes get replicated down then I agree data everywhere should be equally fresh within the time constraints it takes to replicated fully everywhere.

Regards

__________________________________________________ ______________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.

__________________________________________________ ______________________
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Rich Megginson 11-12-2010 05:21 PM

Bind to consumer binds to provider as well
 
Gerrard Geldenhuis wrote:
>>>> Are you using Chain On Update for Binds?
>>>> http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
>>>>
>>>>
>>> We are indeed, we used that howto to set it up. Reading it now again it
>>>
>> does say it will use the chaining backend for binds. Why is that?
>>
>
> Why is that? I don't know .
> According the the wiki http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
> the consumer will use the chaining backend when I do bind/write requests.
>
> I can understand why you would want to "centrally" manage login attempts but would it not better to handle login attempts locally on the consumer and then only if a login attempts fail and you need to do a write then write to the master.
If you are using account policy you will need to keep track globally of
the last login time, so that you can expire the account globally as well.
> I can imagine though that with this approach you can potentially have more auth attempts than is allowed for.
>
I guess we need some sort of fine grained approach, so that you would
only chain certain operations, and only under certain conditions. What
would that look like?
>
>> In order to have global password policy. Let's say for example that you have
>> password policy which states accounts are locked out after 3 unsuccessful
>> login attempts. If you have 5 directory servers, each with local password
>> policy, that effectively means an attacker has 15 tries to guess the password
>> instead of 3.
>>
>>> If we replicate changes down to the consumer how can the data be
>>>
>> "fresher" than the consumer?
>>
>
> My sentence was less than ideal. If changes get replicated down then I agree data everywhere should be equally fresh within the time constraints it takes to replicated fully everywhere.
>
> Regards
>
> __________________________________________________ ______________________
> In order to protect our email recipients, Betfair Group use SkyScan from
> MessageLabs to scan all Incoming and Outgoing mail for viruses.
>
> __________________________________________________ ______________________
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Gerrard Geldenhuis 11-12-2010 06:09 PM

Bind to consumer binds to provider as well
 
> -----Original Message-----
> From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-
> bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
> Sent: 12 November 2010 18:22
> To: General discussion list for the 389 Directory server project.
> Subject: Re: [389-users] Bind to consumer binds to provider as well
>
> > I can imagine though that with this approach you can potentially have
> more auth attempts than is allowed for.
> >
> I guess we need some sort of fine grained approach, so that you would only
> chain certain operations, and only under certain conditions. What would
> that look like?

Admittedly my knowledge of the internals is close to zero and I am not sure what the list of possible operations are.

I am also not aware what the motivation behind the current design is.

We had a discussion about the different types of race conditions that one might possibly run into.
A. Current behaviour
All bind requests go to master
Failed logins gets replicated back to consumer

B. Suggested behaviour
All bind requests stay local
Failed bind requests gets chained back to master
Master replicates failed login attempts back to consumer.

In both A and B you could have a higher number of attempts than is actually allowed before the replicated failed login attempts gets written back to consumer where it will stop the user authenticating. There is a marginal potential for higher number of potential requests if you don't chain bind requests. However this would probably only be exposed if someone is trying to programmatically break the system as normal retry time on the console would take longer than the time it would take to replicate failed login attempts back.

If the delay time between the consumer and the chaining backend is quite big then it makes authenticating against the chaining backend rather slow and takes away scalability in my opionion. Although you would need a very high number of bind requests before it becomes a problem. Latency is really the big issue here.

> >
> >> In order to have global password policy. Let's say for example that
> >> you have password policy which states accounts are locked out after 3
> >> unsuccessful login attempts. If you have 5 directory servers, each
> >> with local password policy, that effectively means an attacker has 15
> >> tries to guess the password instead of 3.
> >>
> >>> If we replicate changes down to the consumer how can the data be
> >>>
> >> "fresher" than the consumer?
> >>

__________________________________________________ ______________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.

__________________________________________________ ______________________
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Rich Megginson 11-12-2010 06:21 PM

Bind to consumer binds to provider as well
 
Gerrard Geldenhuis wrote:
>> -----Original Message-----
>> From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-
>> bounces@lists.fedoraproject.org] On Behalf Of Rich Megginson
>> Sent: 12 November 2010 18:22
>> To: General discussion list for the 389 Directory server project.
>> Subject: Re: [389-users] Bind to consumer binds to provider as well
>>
>>
>>> I can imagine though that with this approach you can potentially have
>>>
>> more auth attempts than is allowed for.
>>
>> I guess we need some sort of fine grained approach, so that you would only
>> chain certain operations, and only under certain conditions. What would
>> that look like?
>>
>
> Admittedly my knowledge of the internals is close to zero and I am not sure what the list of possible operations are.
>
> I am also not aware what the motivation behind the current design is.
>
> We had a discussion about the different types of race conditions that one might possibly run into.
> A. Current behaviour
> All bind requests go to master
> Failed logins gets replicated back to consumer
>
> B. Suggested behaviour
> All bind requests stay local
> Failed bind requests gets chained back to master
> Master replicates failed login attempts back to consumer.
>
> In both A and B you could have a higher number of attempts than is actually allowed before the replicated failed login attempts gets written back to consumer where it will stop the user authenticating. There is a marginal potential for higher number of potential requests if you don't chain bind requests. However this would probably only be exposed if someone is trying to programmatically break the system as normal retry time on the console would take longer than the time it would take to replicate failed login attempts back.
>
> If the delay time between the consumer and the chaining backend is quite big then it makes authenticating against the chaining backend rather slow and takes away scalability in my opionion. Although you would need a very high number of bind requests before it becomes a problem. Latency is really the big issue here.
>
Are you using global password policy?
>
>>>> In order to have global password policy. Let's say for example that
>>>> you have password policy which states accounts are locked out after 3
>>>> unsuccessful login attempts. If you have 5 directory servers, each
>>>> with local password policy, that effectively means an attacker has 15
>>>> tries to guess the password instead of 3.
>>>>
>>>>
>>>>> If we replicate changes down to the consumer how can the data be
>>>>>
>>>>>
>>>> "fresher" than the consumer?
>>>>
>>>>
>
> __________________________________________________ ______________________
> In order to protect our email recipients, Betfair Group use SkyScan from
> MessageLabs to scan all Incoming and Outgoing mail for viruses.
>
> __________________________________________________ ______________________
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Gerrard Geldenhuis 11-15-2010 08:45 AM

Bind to consumer binds to provider as well
 
> >
> > In both A and B you could have a higher number of attempts than is
> actually allowed before the replicated failed login attempts gets written
> back to consumer where it will stop the user authenticating. There is a
> marginal potential for higher number of potential requests if you don't
> chain bind requests. However this would probably only be exposed if
> someone is trying to programmatically break the system as normal retry
> time on the console would take longer than the time it would take to
> replicate failed login attempts back.
> >
> > If the delay time between the consumer and the chaining backend is quite
> big then it makes authenticating against the chaining backend rather slow
> and takes away scalability in my opionion. Although you would need a very
> high number of bind requests before it becomes a problem. Latency is really
> the big issue here.
> >
> Are you using global password policy?
> >

Yes we are using the global password policy. The policy is enforced on the consumers to which the client authenticates but not on the providers which is firewalled off from any direct clients.

Regards


__________________________________________________ ______________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.

__________________________________________________ ______________________
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Roberto Polli 11-29-2010 08:15 AM

Bind to consumer binds to provider as well
 
I think the point is quite real.

The "bind" operation can be the large part of traffic for authentication
systems.

Could be worth to file an issue/wish on bugzilla and continue the discussion
there?

Peace,
R.

--
Roberto Polli
Project Manager
Babel S.r.l. - http://www.babel.it
T: +39.06.91801075 M: +39.340.6522736 F: +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere
confidenziale per i destinatari in indirizzo.
E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati
nel messaggio originale.
Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di
comunicarlo al mittente e cancellarlo immediatamente.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


All times are GMT. The time now is 10:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.