Re: [Freeipa-devel] ipapwd_extop vs password_extop
On 06/07/2016 03:47 PM, Alexander Bokovoy wrote:
On Tue, 07 Jun 2016, thierry bordaz wrote:
Well here we have IPA password extop that receives a 'compat'
entry. This compat entry does not exist except in slapi-nis that
can do the mapping to the real entry. What I was thinking of was
some kind of call from IPA password extop to slapi-nis that for a
given entry DN return the real entryDN. But the tranformation of
the extop('compat') -> extop('real') would be done in IPA password
extop
no, just look at slapi-nis code to see how we rewrite DN of the
request.
You'd need to do a similar trick.
Thanks for the pointer. What differs is that slapi-nis is doing the
mapping in an operation (here bind) preop.
But with extop there is no preop call. Mapping looks to be done in
backend_locate, my understanding is that we need to find a way to
call something like backend_locate from extop and it can not be done
with an internal search because slapi-nis ignores them.
May be it is time to add pre/post operations for extop? Granted, they
are not going to be useful for most cases but this would solve our
problem, right?
Right but it creates a dependency on DS.
An other option would be to use the broker api (to allow a plugin to
call others plugins callback), but it would require changes on slapi-nis
and IPA pwd extop.
The nicer approach is a extop - preop/postop. I will start on this.
Thanks you for all you feedback
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] ipapwd_extop vs password_extop
On Tue, 07 Jun 2016, thierry bordaz wrote:
Well here we have IPA password extop that receives a 'compat'
entry. This compat entry does not exist except in slapi-nis that
can do the mapping to the real entry. What I was thinking of was
some kind of call from IPA password extop to slapi-nis that for a
given entry DN return the real entryDN. But the tranformation of
the extop('compat') -> extop('real') would be done in IPA password
extop
no, just look at slapi-nis code to see how we rewrite DN of the request.
You'd need to do a similar trick.
Thanks for the pointer. What differs is that slapi-nis is doing the
mapping in an operation (here bind) preop.
But with extop there is no preop call. Mapping looks to be done in
backend_locate, my understanding is that we need to find a way to call
something like backend_locate from extop and it can not be done with
an internal search because slapi-nis ignores them.
May be it is time to add pre/post operations for extop? Granted, they
are not going to be useful for most cases but this would solve our
problem, right?
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] ipapwd_extop vs password_extop
On 06/07/2016 01:20 PM, Alexander Bokovoy wrote:
On Tue, 07 Jun 2016, thierry bordaz wrote:
On 06/06/2016 07:12 PM, Alexander Bokovoy wrote:
On Mon, 06 Jun 2016, thierry bordaz wrote:
On 06/06/2016 11:07 AM, Alexander Bokovoy wrote:
On Mon, 06 Jun 2016, thierry bordaz wrote:
Hello,
In DS it is possible to register callbacks for extended op.
For https://www.ietf.org/rfc/rfc3062.txt (password modify extop),
there is a default callback that is implemented in DS core server.
Freeipa enables a plugin 'cn=ipa_pwd_extop,cn=plugins,cn=config'
that also register a callback ipapwd_extop/ipapwd_chpwop, for that
same extop.
The server calls the callbacks until it can find one that can handle
the OID. But the order is not guaranty.
So the extop can be handled either by password_extop or either by
ipapwd_chpwop.
Those two functions are not doing the same checking/updates.
I would like to confirm if in Freeipa context, if only
ipapwd_extop/ipapwd_chpwop should be called
Correct. I think we have also added plugin priority to allow handling
this type of conflicts gracefully.
The order of the plugins, is based on nsslapd-pluginprecedence.
(The lower precedence is called first)
The problem is that ipapw_extop and password_extop have the same
precedence: 50. So the order they are selected basically rely on
order they were registered.
"Password Modify extended operation plugin" (core server) is
registered before "IPA Password Extended Operation plugin".
I think we need to add a precedence of "IPA Password Extended
Operation plugin" to be sure it will be selected over "Password
Modify extended operation plugin"
In addition https://fedorahosted.org/389/ticket/48770 changed the
way plugins are selected so even setting a precedence is currently
not a solution (I opened https://fedorahosted.org/389/ticket/48870)
In short we need to fix https://fedorahosted.org/389/ticket/48870
Regarding item 5.4, replacing a compat entry with its related real
entry.
I think there is something missing. In fact the extop is doing an
internal MOD but before calling the MOD it checks the entry exists.
And if called against a 'compat' entry the extop fails before
calling the MOD.
But even if it was successfull it may be not be a good idea to make
'Schema Compat' preop-mod doing the mapping 'compat' -> real for
all MODS.
given that schema compat is read-only (always), you can do remapping
all
the time. We have this mapping already for password checks, how is this
different?
It should be similar to mapping done for password check. When is it
triggered or where is the code for this mapping ?
See slapi-nis/src/back-sch.c:backend_bind_cb() for details.
A option is to change "IPA Password Extended Operation plugin" to
do this mapping 'compat' -> 'real' but it is looking like a hack.
Yes, it is unacceptable.
Well here we have IPA password extop that receives a 'compat' entry.
This compat entry does not exist except in slapi-nis that can do the
mapping to the real entry. What I was thinking of was some kind of
call from IPA password extop to slapi-nis that for a given entry DN
return the real entryDN. But the tranformation of the extop('compat')
-> extop('real') would be done in IPA password extop
no, just look at slapi-nis code to see how we rewrite DN of the request.
You'd need to do a similar trick.
Thanks for the pointer. What differs is that slapi-nis is doing the
mapping in an operation (here bind) preop.
But with extop there is no preop call. Mapping looks to be done in
backend_locate, my understanding is that we need to find a way to call
something like backend_locate from extop and it can not be done with an
internal search because slapi-nis ignores them.
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] ipapwd_extop vs password_extop
On Tue, 07 Jun 2016, thierry bordaz wrote:
On 06/06/2016 07:12 PM, Alexander Bokovoy wrote:
On Mon, 06 Jun 2016, thierry bordaz wrote:
On 06/06/2016 11:07 AM, Alexander Bokovoy wrote:
On Mon, 06 Jun 2016, thierry bordaz wrote:
Hello,
In DS it is possible to register callbacks for extended op.
For https://www.ietf.org/rfc/rfc3062.txt (password modify extop),
there is a default callback that is implemented in DS core server.
Freeipa enables a plugin 'cn=ipa_pwd_extop,cn=plugins,cn=config'
that also register a callback ipapwd_extop/ipapwd_chpwop, for that
same extop.
The server calls the callbacks until it can find one that can handle
the OID. But the order is not guaranty.
So the extop can be handled either by password_extop or either by
ipapwd_chpwop.
Those two functions are not doing the same checking/updates.
I would like to confirm if in Freeipa context, if only
ipapwd_extop/ipapwd_chpwop should be called
Correct. I think we have also added plugin priority to allow handling
this type of conflicts gracefully.
The order of the plugins, is based on nsslapd-pluginprecedence.
(The lower precedence is called first)
The problem is that ipapw_extop and password_extop have the same
precedence: 50. So the order they are selected basically rely on
order they were registered.
"Password Modify extended operation plugin" (core server) is
registered before "IPA Password Extended Operation plugin".
I think we need to add a precedence of "IPA Password Extended
Operation plugin" to be sure it will be selected over "Password
Modify extended operation plugin"
In addition https://fedorahosted.org/389/ticket/48770 changed the
way plugins are selected so even setting a precedence is currently
not a solution (I opened
https://fedorahosted.org/389/ticket/48870)
In short we need to fix https://fedorahosted.org/389/ticket/48870
Regarding item 5.4, replacing a compat entry with its related real
entry.
I think there is something missing. In fact the extop is doing an
internal MOD but before calling the MOD it checks the entry
exists. And if called against a 'compat' entry the extop fails
before calling the MOD.
But even if it was successfull it may be not be a good idea to
make 'Schema Compat' preop-mod doing the mapping 'compat' -> real
for all MODS.
given that schema compat is read-only (always), you can do remapping all
the time. We have this mapping already for password checks, how is this
different?
It should be similar to mapping done for password check. When is it
triggered or where is the code for this mapping ?
See slapi-nis/src/back-sch.c:backend_bind_cb() for details.
A option is to change "IPA Password Extended Operation plugin" to
do this mapping 'compat' -> 'real' but it is looking like a hack.
Yes, it is unacceptable.
Well here we have IPA password extop that receives a 'compat' entry.
This compat entry does not exist except in slapi-nis that can do the
mapping to the real entry. What I was thinking of was some kind of
call from IPA password extop to slapi-nis that for a given entry DN
return the real entryDN. But the tranformation of the extop('compat')
-> extop('real') would be done in IPA password extop
no, just look at slapi-nis code to see how we rewrite DN of the request.
You'd need to do a similar trick.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] ipapwd_extop vs password_extop
On 06/06/2016 07:12 PM, Alexander Bokovoy wrote:
On Mon, 06 Jun 2016, thierry bordaz wrote:
On 06/06/2016 11:07 AM, Alexander Bokovoy wrote:
On Mon, 06 Jun 2016, thierry bordaz wrote:
Hello,
In DS it is possible to register callbacks for extended op.
For https://www.ietf.org/rfc/rfc3062.txt (password modify extop),
there is a default callback that is implemented in DS core server.
Freeipa enables a plugin 'cn=ipa_pwd_extop,cn=plugins,cn=config'
that also register a callback ipapwd_extop/ipapwd_chpwop, for that
same extop.
The server calls the callbacks until it can find one that can handle
the OID. But the order is not guaranty.
So the extop can be handled either by password_extop or either by
ipapwd_chpwop.
Those two functions are not doing the same checking/updates.
I would like to confirm if in Freeipa context, if only
ipapwd_extop/ipapwd_chpwop should be called
Correct. I think we have also added plugin priority to allow handling
this type of conflicts gracefully.
The order of the plugins, is based on nsslapd-pluginprecedence.
(The lower precedence is called first)
The problem is that ipapw_extop and password_extop have the same
precedence: 50. So the order they are selected basically rely on
order they were registered.
"Password Modify extended operation plugin" (core server) is
registered before "IPA Password Extended Operation plugin".
I think we need to add a precedence of "IPA Password Extended
Operation plugin" to be sure it will be selected over "Password
Modify extended operation plugin"
In addition https://fedorahosted.org/389/ticket/48770 changed the way
plugins are selected so even setting a precedence is currently not a
solution (I opened https://fedorahosted.org/389/ticket/48870)
In short we need to fix https://fedorahosted.org/389/ticket/48870
Regarding item 5.4, replacing a compat entry with its related real
entry.
I think there is something missing. In fact the extop is doing an
internal MOD but before calling the MOD it checks the entry exists.
And if called against a 'compat' entry the extop fails before calling
the MOD.
But even if it was successfull it may be not be a good idea to make
'Schema Compat' preop-mod doing the mapping 'compat' -> real for all
MODS.
given that schema compat is read-only (always), you can do remapping all
the time. We have this mapping already for password checks, how is this
different?
It should be similar to mapping done for password check. When is it
triggered or where is the code for this mapping ?
A option is to change "IPA Password Extended Operation plugin" to do
this mapping 'compat' -> 'real' but it is looking like a hack.
Yes, it is unacceptable.
Well here we have IPA password extop that receives a 'compat' entry.
This compat entry does not exist except in slapi-nis that can do the
mapping to the real entry. What I was thinking of was some kind of call
from IPA password extop to slapi-nis that for a given entry DN return
the real entryDN. But the tranformation of the extop('compat') ->
extop('real') would be done in IPA password extop
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] ipapwd_extop vs password_extop
On Mon, 06 Jun 2016, thierry bordaz wrote: On 06/06/2016 11:07 AM, Alexander Bokovoy wrote: On Mon, 06 Jun 2016, thierry bordaz wrote: Hello, In DS it is possible to register callbacks for extended op. For https://www.ietf.org/rfc/rfc3062.txt (password modify extop), there is a default callback that is implemented in DS core server. Freeipa enables a plugin 'cn=ipa_pwd_extop,cn=plugins,cn=config' that also register a callback ipapwd_extop/ipapwd_chpwop, for that same extop. The server calls the callbacks until it can find one that can handle the OID. But the order is not guaranty. So the extop can be handled either by password_extop or either by ipapwd_chpwop. Those two functions are not doing the same checking/updates. I would like to confirm if in Freeipa context, if only ipapwd_extop/ipapwd_chpwop should be called Correct. I think we have also added plugin priority to allow handling this type of conflicts gracefully. The order of the plugins, is based on nsslapd-pluginprecedence. (The lower precedence is called first) The problem is that ipapw_extop and password_extop have the same precedence: 50. So the order they are selected basically rely on order they were registered. "Password Modify extended operation plugin" (core server) is registered before "IPA Password Extended Operation plugin". I think we need to add a precedence of "IPA Password Extended Operation plugin" to be sure it will be selected over "Password Modify extended operation plugin" In addition https://fedorahosted.org/389/ticket/48770 changed the way plugins are selected so even setting a precedence is currently not a solution (I opened https://fedorahosted.org/389/ticket/48870) In short we need to fix https://fedorahosted.org/389/ticket/48870 Regarding item 5.4, replacing a compat entry with its related real entry. I think there is something missing. In fact the extop is doing an internal MOD but before calling the MOD it checks the entry exists. And if called against a 'compat' entry the extop fails before calling the MOD. But even if it was successfull it may be not be a good idea to make 'Schema Compat' preop-mod doing the mapping 'compat' -> real for all MODS. given that schema compat is read-only (always), you can do remapping all the time. We have this mapping already for password checks, how is this different? A option is to change "IPA Password Extended Operation plugin" to do this mapping 'compat' -> 'real' but it is looking like a hack. Yes, it is unacceptable. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] ipapwd_extop vs password_extop
On 06/06/2016 11:07 AM, Alexander Bokovoy wrote: On Mon, 06 Jun 2016, thierry bordaz wrote: Hello, In DS it is possible to register callbacks for extended op. For https://www.ietf.org/rfc/rfc3062.txt (password modify extop), there is a default callback that is implemented in DS core server. Freeipa enables a plugin 'cn=ipa_pwd_extop,cn=plugins,cn=config' that also register a callback ipapwd_extop/ipapwd_chpwop, for that same extop. The server calls the callbacks until it can find one that can handle the OID. But the order is not guaranty. So the extop can be handled either by password_extop or either by ipapwd_chpwop. Those two functions are not doing the same checking/updates. I would like to confirm if in Freeipa context, if only ipapwd_extop/ipapwd_chpwop should be called Correct. I think we have also added plugin priority to allow handling this type of conflicts gracefully. The order of the plugins, is based on nsslapd-pluginprecedence. (The lower precedence is called first) The problem is that ipapw_extop and password_extop have the same precedence: 50. So the order they are selected basically rely on order they were registered. "Password Modify extended operation plugin" (core server) is registered before "IPA Password Extended Operation plugin". I think we need to add a precedence of "IPA Password Extended Operation plugin" to be sure it will be selected over "Password Modify extended operation plugin" In addition https://fedorahosted.org/389/ticket/48770 changed the way plugins are selected so even setting a precedence is currently not a solution (I opened https://fedorahosted.org/389/ticket/48870) In short we need to fix https://fedorahosted.org/389/ticket/48870 Regarding item 5.4, replacing a compat entry with its related real entry. I think there is something missing. In fact the extop is doing an internal MOD but before calling the MOD it checks the entry exists. And if called against a 'compat' entry the extop fails before calling the MOD. But even if it was successfull it may be not be a good idea to make 'Schema Compat' preop-mod doing the mapping 'compat' -> real for all MODS. A option is to change "IPA Password Extended Operation plugin" to do this mapping 'compat' -> 'real' but it is looking like a hack. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] ipapwd_extop vs password_extop
On Mon, 06 Jun 2016, thierry bordaz wrote: Hello, In DS it is possible to register callbacks for extended op. For https://www.ietf.org/rfc/rfc3062.txt (password modify extop), there is a default callback that is implemented in DS core server. Freeipa enables a plugin 'cn=ipa_pwd_extop,cn=plugins,cn=config' that also register a callback ipapwd_extop/ipapwd_chpwop, for that same extop. The server calls the callbacks until it can find one that can handle the OID. But the order is not guaranty. So the extop can be handled either by password_extop or either by ipapwd_chpwop. Those two functions are not doing the same checking/updates. I would like to confirm if in Freeipa context, if only ipapwd_extop/ipapwd_chpwop should be called Correct. I think we have also added plugin priority to allow handling this type of conflicts gracefully. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
