Correction: -w <passwd> or -w - instead of -W
On Thu, Oct 28, 2010 at 15:02, Benjamin Griese der.darude@gmail.com wrote:
Hello Günther,
sorry for my late reply, I hate sun cluster panics after patching those beasts. :(
Here is the content of solaris_profile:
dn: cn=solaris_profile,ou=profile,dc=example,dc=de objectClass: DUAConfigProfile objectClass: top cn: solaris_profile authenticationMethod: simple bindTimeLimit: 10 credentialLevel: proxy defaultSearchBase: dc=example,dc=de defaultSearchScope: sub defaultServerList: exampleldap01 exampleldap02 (syncrepl, configured to mirrormode) followReferrals: FALSE profileTTL: 3600 searchTimeLimit: 30 serviceSearchDescriptor: sudoers:ou=SUDOers,dc=example,dc=de?sub serviceSearchDescriptor: group:ou=groups,dc=example,dc=de?sub serviceSearchDescriptor: passwd:ou=people,dc=example,dc=de?sub
Regarding to the sorting I found this in man ldapsearch:
"-F sep
Use sep as the field separator between attribute names and values. If this option has been specified, the -L option is ignored.
-S [-]attribute
Specify an attribute for sorting the entries returned by the search. The sort criteria is alphabetical on the attribute's value or reverse alphabetical with the form -attribute. You can give multiple -S options to refine the sorting, For example:
-S sn -S givenname
By default, the entries are not sorted. Use the -x option to perform server-side sorting."
If I use -x for server side sorting, I get the complete list of uid-Objects, but not sorted in any obvious way: # ldapsearch -v -x -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:16:49 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) version: 1
If I use this string I get the complete list of uid-objects sorted by uidNumber # ldapsearch -v -S uidnumber -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:37:11 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) version: 1
If I try to search with -x and -S uidnumber I get the same message that appears in the OpenLDAP logfile: # ldapsearch -v -x -S uidNumber -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:25:50 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) ldap_search: Inappropriate matching ldap_search: additional info: serverSort control: No ordering rule ldap_parse_sort_control: Requested LDAP control not found
Finally I still have no clue how to prevent the client from doing these kinds of searches. And I couldn't find any templates regarding the ldapclient on my test machine.
Any other clues or ideas?
Bye, Benjamin.
On Sat, Oct 23, 2010 at 19:17, Dieter Kluenter dieter@dkluenter.de wrote:
Benjamin Griese der.darude@gmail.com writes:
Hey thanks for quick reply,
I put the config of the ldapclient on the ML some days ago, but I can't figure out how I may have set such a rule on client side. Probably it is something hardcoded.
ldapclient config: NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyuser,ou=system,ou=people,dc=example,dc=de NS_LDAP_BINDPASSWD= secret NS_LDAP_SERVERS= ldap01 NS_LDAP_SEARCH_BASEDN= dc=example,dc=de NS_LDAP_AUTH= simple NS_LDAP_SEARCH_REF= FALSE NS_LDAP_SEARCH_SCOPE= sub NS_LDAP_SEARCH_TIME= 30 NS_LDAP_CACHETTL= 60 NS_LDAP_PROFILE= solaris_profile NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=people,dc=example,dc=de?sub NS_LDAP_SERVICE_SEARCH_DESC= group: ou=groups,dc=example,dc=de?sub NS_LDAP_SERVICE_SEARCH_DESC= sudoers: ou=SUDOers,dc=example,dc=de?sub
That's all I setup, its like defaultest of the defaultest I guess :)
And thanks for describing EQUALITY.
I must admit I am not that familiar with old netscape tools, but the openldap log ist quite clear, there is a request for a Server Side Sorting extended operation, which in fact is quite unusual. You really should check Solaris 10 setup for appropriate templates, i.e. what is the content of solaris_profile? By the way, AFAIR the flag for sss is -F so you may check any templates, Redhat provides these in /usr/share/dirsrv, Solaris might be different.
-Dieter
-- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
While further searching the web I found this nice conclusion of how to debug a Solaris 10 Native LDAP-Client or more general, what is neccessary to know if you want to work with solaris native ldap client.
http://wiki.genunix.org/wiki/index.php/Native_LDAP_Product_Support_Document#... I am a little bit concerned about the VLV support of OpenLDAP, I don't know how to disable this feature without compiling my own packages and disable that by configure.
This discussion is about disabling VLV to be able to work with the solaris native ldap client and AD: http://old.nabble.com/Solaris-native-ldap-client-to-Windows-Active-Directory...
Can somebody agree to that problem with VLVs and the solaris native ldap client?
Thanks and bye.
On Thu, Oct 28, 2010 at 15:12, Benjamin Griese der.darude@gmail.com wrote:
Correction: -w <passwd> or -w - instead of -W
On Thu, Oct 28, 2010 at 15:02, Benjamin Griese der.darude@gmail.com wrote:
Hello Günther,
sorry for my late reply, I hate sun cluster panics after patching those beasts. :(
Here is the content of solaris_profile:
dn: cn=solaris_profile,ou=profile,dc=example,dc=de objectClass: DUAConfigProfile objectClass: top cn: solaris_profile authenticationMethod: simple bindTimeLimit: 10 credentialLevel: proxy defaultSearchBase: dc=example,dc=de defaultSearchScope: sub defaultServerList: exampleldap01 exampleldap02 (syncrepl, configured to mirrormode) followReferrals: FALSE profileTTL: 3600 searchTimeLimit: 30 serviceSearchDescriptor: sudoers:ou=SUDOers,dc=example,dc=de?sub serviceSearchDescriptor: group:ou=groups,dc=example,dc=de?sub serviceSearchDescriptor: passwd:ou=people,dc=example,dc=de?sub
Regarding to the sorting I found this in man ldapsearch:
"-F sep
Use sep as the field separator between attribute names and values. If this option has been specified, the -L option is ignored.
-S [-]attribute
Specify an attribute for sorting the entries returned by the search. The sort criteria is alphabetical on the attribute's value or reverse alphabetical with the form -attribute. You can give multiple -S options to refine the sorting, For example:
-S sn -S givenname
By default, the entries are not sorted. Use the -x option to perform server-side sorting."
If I use -x for server side sorting, I get the complete list of uid-Objects, but not sorted in any obvious way: # ldapsearch -v -x -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:16:49 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) version: 1
If I use this string I get the complete list of uid-objects sorted by uidNumber # ldapsearch -v -S uidnumber -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:37:11 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) version: 1
If I try to search with -x and -S uidnumber I get the same message that appears in the OpenLDAP logfile: # ldapsearch -v -x -S uidNumber -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:25:50 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) ldap_search: Inappropriate matching ldap_search: additional info: serverSort control: No ordering rule ldap_parse_sort_control: Requested LDAP control not found
Finally I still have no clue how to prevent the client from doing these kinds of searches. And I couldn't find any templates regarding the ldapclient on my test machine.
Any other clues or ideas?
Bye, Benjamin.
On Sat, Oct 23, 2010 at 19:17, Dieter Kluenter dieter@dkluenter.de wrote:
Benjamin Griese der.darude@gmail.com writes:
Hey thanks for quick reply,
I put the config of the ldapclient on the ML some days ago, but I can't figure out how I may have set such a rule on client side. Probably it is something hardcoded.
ldapclient config: NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyuser,ou=system,ou=people,dc=example,dc=de NS_LDAP_BINDPASSWD= secret NS_LDAP_SERVERS= ldap01 NS_LDAP_SEARCH_BASEDN= dc=example,dc=de NS_LDAP_AUTH= simple NS_LDAP_SEARCH_REF= FALSE NS_LDAP_SEARCH_SCOPE= sub NS_LDAP_SEARCH_TIME= 30 NS_LDAP_CACHETTL= 60 NS_LDAP_PROFILE= solaris_profile NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=people,dc=example,dc=de?sub NS_LDAP_SERVICE_SEARCH_DESC= group: ou=groups,dc=example,dc=de?sub NS_LDAP_SERVICE_SEARCH_DESC= sudoers: ou=SUDOers,dc=example,dc=de?sub
That's all I setup, its like defaultest of the defaultest I guess :)
And thanks for describing EQUALITY.
I must admit I am not that familiar with old netscape tools, but the openldap log ist quite clear, there is a request for a Server Side Sorting extended operation, which in fact is quite unusual. You really should check Solaris 10 setup for appropriate templates, i.e. what is the content of solaris_profile? By the way, AFAIR the flag for sss is -F so you may check any templates, Redhat provides these in /usr/share/dirsrv, Solaris might be different.
-Dieter
-- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
Benjamin,
We have a similar problem where upgrading to OpenLDAP 2.4.20 on SLES 11 causes Outlook 2003 clients to not work right with an ldap address book on OpenLDAP. Microsoft has this documented here:
http://support.microsoft.com/kb/555536
In this case, the reg hack works.
I can't say whether the actual issue is Outlook's (or Solaris Native LDAP in your case) miss-use of this server side control or the sssvlv overlay. Regardless of the root cause, I don't *need* the server side controls provided by the sssvlv overlay and would just assume disable it.
Unfortunately, Novell does not compile OpenLDAP overlays as modules in their SuSE Linux distribution so the overlay can't be disabled. I am in the same position that it seems a lot of people are with being unable to compile OpenLDAP myself without losing the paid-for Novell support. We have already contacted Novell, explained our position, and asked for them to change their configuration of this package. It seems as though they might be more likely to do so if several customers contact them.
Hope that helps,
James Bagley Jr
On 10/28/10 7:04 AM, "Benjamin Griese" der.darude@gmail.com wrote:
While further searching the web I found this nice conclusion of how to debug a Solaris 10 Native LDAP-Client or more general, what is neccessary to know if you want to work with solaris native ldap client.
http://wiki.genunix.org/wiki/index.php/Native_LDAP_Product_Support_Document#... at_are_the_requirements_for_Directory_server_to_support_Solaris_Native_LDAP_cl ients.3F I am a little bit concerned about the VLV support of OpenLDAP, I don't know how to disable this feature without compiling my own packages and disable that by configure.
This discussion is about disabling VLV to be able to work with the solaris native ldap client and AD: http://old.nabble.com/Solaris-native-ldap-client-to-Windows-Active-Directory... Netgroups-don't-work-because-of-control-critical-statement-tt23075436.html#a23 075436
Can somebody agree to that problem with VLVs and the solaris native ldap client?
Thanks and bye.
On Thu, Oct 28, 2010 at 15:12, Benjamin Griese der.darude@gmail.com wrote:
Correction: -w <passwd> or -w - instead of -W
On Thu, Oct 28, 2010 at 15:02, Benjamin Griese der.darude@gmail.com wrote:
Hello Günther,
sorry for my late reply, I hate sun cluster panics after patching those beasts. :(
Here is the content of solaris_profile:
dn: cn=solaris_profile,ou=profile,dc=example,dc=de objectClass: DUAConfigProfile objectClass: top cn: solaris_profile authenticationMethod: simple bindTimeLimit: 10 credentialLevel: proxy defaultSearchBase: dc=example,dc=de defaultSearchScope: sub defaultServerList: exampleldap01 exampleldap02 (syncrepl, configured to mirrormode) followReferrals: FALSE profileTTL: 3600 searchTimeLimit: 30 serviceSearchDescriptor: sudoers:ou=SUDOers,dc=example,dc=de?sub serviceSearchDescriptor: group:ou=groups,dc=example,dc=de?sub serviceSearchDescriptor: passwd:ou=people,dc=example,dc=de?sub
Regarding to the sorting I found this in man ldapsearch:
"-F sep
Use sep as the field separator between attribute names and values. If this option has been specified, the -L option is ignored.
-S [-]attribute
Specify an attribute for sorting the entries returned by the search. The sort criteria is alphabetical on the attribute's value or reverse alphabetical with the form -attribute. You can give multiple -S options to refine the sorting, For example:
-S sn -S givenname
By default, the entries are not sorted. Use the -x option to perform server-side sorting."
If I use -x for server side sorting, I get the complete list of uid-Objects, but not sorted in any obvious way: # ldapsearch -v -x -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:16:49 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) version: 1
If I use this string I get the complete list of uid-objects sorted by uidNumber # ldapsearch -v -S uidnumber -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:37:11 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) version: 1
If I try to search with -x and -S uidnumber I get the same message that appears in the OpenLDAP logfile: # ldapsearch -v -x -S uidNumber -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:25:50 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) ldap_search: Inappropriate matching ldap_search: additional info: serverSort control: No ordering rule ldap_parse_sort_control: Requested LDAP control not found
Finally I still have no clue how to prevent the client from doing these kinds of searches. And I couldn't find any templates regarding the ldapclient on my test machine.
Any other clues or ideas?
Bye, Benjamin.
On Sat, Oct 23, 2010 at 19:17, Dieter Kluenter dieter@dkluenter.de wrote:
Benjamin Griese der.darude@gmail.com writes:
Hey thanks for quick reply,
I put the config of the ldapclient on the ML some days ago, but I can't figure out how I may have set such a rule on client side. Probably it is something hardcoded.
ldapclient config: NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyuser,ou=system,ou=people,dc=example,dc=de NS_LDAP_BINDPASSWD= secret NS_LDAP_SERVERS= ldap01 NS_LDAP_SEARCH_BASEDN= dc=example,dc=de NS_LDAP_AUTH= simple NS_LDAP_SEARCH_REF= FALSE NS_LDAP_SEARCH_SCOPE= sub NS_LDAP_SEARCH_TIME= 30 NS_LDAP_CACHETTL= 60 NS_LDAP_PROFILE= solaris_profile NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=people,dc=example,dc=de?sub NS_LDAP_SERVICE_SEARCH_DESC= group: ou=groups,dc=example,dc=de?sub NS_LDAP_SERVICE_SEARCH_DESC= sudoers: ou=SUDOers,dc=example,dc=de?sub
That's all I setup, its like defaultest of the defaultest I guess :)
And thanks for describing EQUALITY.
I must admit I am not that familiar with old netscape tools, but the openldap log ist quite clear, there is a request for a Server Side Sorting extended operation, which in fact is quite unusual. You really should check Solaris 10 setup for appropriate templates, i.e. what is the content of solaris_profile? By the way, AFAIR the flag for sss is -F so you may check any templates, Redhat provides these in /usr/share/dirsrv, Solaris might be different.
-Dieter
-- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
Hello James,
thanks for replying giving us your opinion. Sometimes I thought I was the only person who has the problem you're talking of. I am in the same dilemma as you are, using SLES11 /w SP1 and have a not working solaris nativ ldap client oder downgrading to SLES1 /wo SP1 but using a rather outdated version of OpenLDAP 2.4.12 but seems to work with the solaris ldap client and your outlook 2003 client.
The problem is, Novell won't release any package changes in endless time, probably für SP2 at earliest point in time. To get/keep it working you have to stay on the older version and I have to downgrade. This is a quite annoying state of a problem we have here.
I'll point out the problem to my boss, maybe there is something I can do about it, but for my own laziness, I don't want to regurlarly check for/download/recompile the OpenLDAP package in the lifetime of the server to fix some particular security issues.
So what are we going to do in the meantime? At my site, everything except listing of user/groups is working on the client side, not that big of an issue, but thats also true for dynamic lists that I wanted to use and thats a big issue. :/
How is your state and how big is the problem?
Bye, Benjamin.
PS: Dieter, I tried to get the list of supported controls from the server via the solaris client, but had not luck.
On Thu, Oct 28, 2010 at 17:54, James Bagley Jr james.bagley@state.or.us wrote:
Benjamin,
We have a similar problem where upgrading to OpenLDAP 2.4.20 on SLES 11 causes Outlook 2003 clients to not work right with an ldap address book on OpenLDAP. Microsoft has this documented here:
http://support.microsoft.com/kb/555536
In this case, the reg hack works.
I can't say whether the actual issue is Outlook's (or Solaris Native LDAP in your case) miss-use of this server side control or the sssvlv overlay. Regardless of the root cause, I don't *need* the server side controls provided by the sssvlv overlay and would just assume disable it.
Unfortunately, Novell does not compile OpenLDAP overlays as modules in their SuSE Linux distribution so the overlay can't be disabled. I am in the same position that it seems a lot of people are with being unable to compile OpenLDAP myself without losing the paid-for Novell support. We have already contacted Novell, explained our position, and asked for them to change their configuration of this package. It seems as though they might be more likely to do so if several customers contact them.
Hope that helps,
James Bagley Jr
On 10/28/10 7:04 AM, "Benjamin Griese" der.darude@gmail.com wrote:
While further searching the web I found this nice conclusion of how to debug a Solaris 10 Native LDAP-Client or more general, what is neccessary to know if you want to work with solaris native ldap client.
http://wiki.genunix.org/wiki/index.php/Native_LDAP_Product_Support_Document#... at_are_the_requirements_for_Directory_server_to_support_Solaris_Native_LDAP_cl ients.3F I am a little bit concerned about the VLV support of OpenLDAP, I don't know how to disable this feature without compiling my own packages and disable that by configure.
This discussion is about disabling VLV to be able to work with the solaris native ldap client and AD: http://old.nabble.com/Solaris-native-ldap-client-to-Windows-Active-Directory... Netgroups-don't-work-because-of-control-critical-statement-tt23075436.html#a23 075436
Can somebody agree to that problem with VLVs and the solaris native ldap client?
Thanks and bye.
On Thu, Oct 28, 2010 at 15:12, Benjamin Griese der.darude@gmail.com wrote:
Correction: -w <passwd> or -w - instead of -W
On Thu, Oct 28, 2010 at 15:02, Benjamin Griese der.darude@gmail.com wrote:
Hello Günther,
sorry for my late reply, I hate sun cluster panics after patching those beasts. :(
Here is the content of solaris_profile:
dn: cn=solaris_profile,ou=profile,dc=example,dc=de objectClass: DUAConfigProfile objectClass: top cn: solaris_profile authenticationMethod: simple bindTimeLimit: 10 credentialLevel: proxy defaultSearchBase: dc=example,dc=de defaultSearchScope: sub defaultServerList: exampleldap01 exampleldap02 (syncrepl, configured to mirrormode) followReferrals: FALSE profileTTL: 3600 searchTimeLimit: 30 serviceSearchDescriptor: sudoers:ou=SUDOers,dc=example,dc=de?sub serviceSearchDescriptor: group:ou=groups,dc=example,dc=de?sub serviceSearchDescriptor: passwd:ou=people,dc=example,dc=de?sub
Regarding to the sorting I found this in man ldapsearch:
"-F sep
Use sep as the field separator between attribute names and values. If this option has been specified, the -L option is ignored.
-S [-]attribute
Specify an attribute for sorting the entries returned by the search. The sort criteria is alphabetical on the attribute's value or reverse alphabetical with the form -attribute. You can give multiple -S options to refine the sorting, For example:
-S sn -S givenname
By default, the entries are not sorted. Use the -x option to perform server-side sorting."
If I use -x for server side sorting, I get the complete list of uid-Objects, but not sorted in any obvious way: # ldapsearch -v -x -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:16:49 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) version: 1
If I use this string I get the complete list of uid-objects sorted by uidNumber # ldapsearch -v -S uidnumber -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:37:11 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) version: 1
If I try to search with -x and -S uidnumber I get the same message that appears in the OpenLDAP logfile: # ldapsearch -v -x -S uidNumber -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:25:50 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) ldap_search: Inappropriate matching ldap_search: additional info: serverSort control: No ordering rule ldap_parse_sort_control: Requested LDAP control not found
Finally I still have no clue how to prevent the client from doing these kinds of searches. And I couldn't find any templates regarding the ldapclient on my test machine.
Any other clues or ideas?
Bye, Benjamin.
On Sat, Oct 23, 2010 at 19:17, Dieter Kluenter dieter@dkluenter.de wrote:
Benjamin Griese der.darude@gmail.com writes:
Hey thanks for quick reply,
I put the config of the ldapclient on the ML some days ago, but I can't figure out how I may have set such a rule on client side. Probably it is something hardcoded.
ldapclient config: NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_BINDDN= cn=proxyuser,ou=system,ou=people,dc=example,dc=de NS_LDAP_BINDPASSWD= secret NS_LDAP_SERVERS= ldap01 NS_LDAP_SEARCH_BASEDN= dc=example,dc=de NS_LDAP_AUTH= simple NS_LDAP_SEARCH_REF= FALSE NS_LDAP_SEARCH_SCOPE= sub NS_LDAP_SEARCH_TIME= 30 NS_LDAP_CACHETTL= 60 NS_LDAP_PROFILE= solaris_profile NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=people,dc=example,dc=de?sub NS_LDAP_SERVICE_SEARCH_DESC= group: ou=groups,dc=example,dc=de?sub NS_LDAP_SERVICE_SEARCH_DESC= sudoers: ou=SUDOers,dc=example,dc=de?sub
That's all I setup, its like defaultest of the defaultest I guess :)
And thanks for describing EQUALITY.
I must admit I am not that familiar with old netscape tools, but the openldap log ist quite clear, there is a request for a Server Side Sorting extended operation, which in fact is quite unusual. You really should check Solaris 10 setup for appropriate templates, i.e. what is the content of solaris_profile? By the way, AFAIR the flag for sss is -F so you may check any templates, Redhat provides these in /usr/share/dirsrv, Solaris might be different.
-Dieter
-- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
Am Donnerstag 28 Oktober 2010, 19:57:17 schrieb Benjamin Griese:
Hello James,
thanks for replying giving us your opinion. Sometimes I thought I was the only person who has the problem you're talking of. I am in the same dilemma as you are, using SLES11 /w SP1 and have a not working solaris nativ ldap client oder downgrading to SLES1 /wo SP1 but using a rather outdated version of OpenLDAP 2.4.12 but seems to work with the solaris ldap client and your outlook 2003 client.
The problem is, Novell won't release any package changes in endless time, probably für SP2 at earliest point in time. To get/keep it working you have to stay on the older version and I have to downgrade. This is a quite annoying state of a problem we have here.
FYI, we (Novell) are currently working on releasing an update to fix this problem. I can't tell you when it will get released, yet. But it will for sure be before SLES11 SP2.
Until then a possible workaround could be to use some clever ACL to filter the OIDs of VLV and Server Side Sort from the supportedControl Attribute of the rootDSE.
I'll point out the problem to my boss, maybe there is something I can do about it, but for my own laziness, I don't want to regurlarly check for/download/recompile the OpenLDAP package in the lifetime of the server to fix some particular security issues.
So what are we going to do in the meantime? At my site, everything except listing of user/groups is working on the client side, not that big of an issue, but thats also true for dynamic lists that I wanted to use and thats a big issue. :/
How is your state and how big is the problem?
Bye, Benjamin.
PS: Dieter, I tried to get the list of supported controls from the server via the solaris client, but had not luck.
[..]
Hello Ralf,
nice to know that someone from Novell is reading here, too.
Currently I have opened up a Service Request regarding this topic at Novells Suport Center and pointed that out as a Feature Request but also as problem I and other people have and are lookinf for a workaround.
Too bad I am really low experienced in building complex ACLs to filter stuff like this, maybe someone else is able to help us (James and me) to workaround that problem.
I'll give it a shot and let you know if it's working or not. :)
Bye, Benjamin.
On Tue, Nov 2, 2010 at 16:05, Ralf Haferkamp rhafer@suse.de wrote:
Am Donnerstag 28 Oktober 2010, 19:57:17 schrieb Benjamin Griese:
Hello James,
thanks for replying giving us your opinion. Sometimes I thought I was the only person who has the problem you're talking of. I am in the same dilemma as you are, using SLES11 /w SP1 and have a not working solaris nativ ldap client oder downgrading to SLES1 /wo SP1 but using a rather outdated version of OpenLDAP 2.4.12 but seems to work with the solaris ldap client and your outlook 2003 client.
The problem is, Novell won't release any package changes in endless time, probably für SP2 at earliest point in time. To get/keep it working you have to stay on the older version and I have to downgrade. This is a quite annoying state of a problem we have here.
FYI, we (Novell) are currently working on releasing an update to fix this problem. I can't tell you when it will get released, yet. But it will for sure be before SLES11 SP2.
Until then a possible workaround could be to use some clever ACL to filter the OIDs of VLV and Server Side Sort from the supportedControl Attribute of the rootDSE.
I'll point out the problem to my boss, maybe there is something I can do about it, but for my own laziness, I don't want to regurlarly check for/download/recompile the OpenLDAP package in the lifetime of the server to fix some particular security issues.
So what are we going to do in the meantime? At my site, everything except listing of user/groups is working on the client side, not that big of an issue, but thats also true for dynamic lists that I wanted to use and thats a big issue. :/
How is your state and how big is the problem?
Bye, Benjamin.
PS: Dieter, I tried to get the list of supported controls from the server via the solaris client, but had not luck.
[..]
-- Ralf
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Am Dienstag 02 November 2010, 16:57:38 schrieb Benjamin Griese:
Hello Ralf,
nice to know that someone from Novell is reading here, too.
Currently I have opened up a Service Request regarding this topic at Novells Suport Center and pointed that out as a Feature Request but also as problem I and other people have and are lookinf for a workaround.
The feature request is regarding build the overlays as dynamic modules, I guess? Yes that's something we are looking into as well. But for this special SSS/VLV issue there is already a fix in CVS which I we will most probably include in our packages. Changing from static overlays to dynamic overlays is unlikely to happen during the SLES11 timeframe I think (but we are getting off topic ...)
Too bad I am really low experienced in building complex ACLs to filter stuff like this, maybe someone else is able to help us (James and me) to workaround that problem.
Something like this should work:
access to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none access to dn.base="" attrs=supportedControl val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none
I just found out however that there seems to be a bug in the ACL code when the above ACL appear as the first ACL in the configuration :(. I am still trying to track down that problem. So please make sure to have another ACL before them (one that doesn't apply to the "supportedControl" Attribute of course).
I'll give it a shot and let you know if it's working or not. :)
Good luck.
Ralf
Hello Ralf,
yes you're right that's the right SR, and yes it's about dynamic loading of modules. I pointed Austin right to you and this thread, just for better communication.
In the meantime I set the ACL, but unfortunatly it didn't help solving the problem, you may take a look at my example:
DN: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=ldapadm,dc=example,dc=de" write by dn="cn=proxyuser,ou=system,ou=people,dc=example,dc=de" read by anonymous auth by self write by * none olcAccess: {1} to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none olcAccess: {2} to dn.base="" attrs=supportedControl val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none olcAccess: {3}to dn.base="" by * read olcAccess: {4}to * by dn="cn=ldapadm,dc=example,dc=de" write by * read
If I remember right {4} is not opening up the access when it is explicitly denied in the ACLs {1} & {2}, am I right? But I'm not sure if this is the right place for this kind of ACL, cn=config instead should be wrong too I guess.
Bye, Benjamin.
On Tue, Nov 2, 2010 at 18:03, Ralf Haferkamp rhafer@suse.de wrote:
Am Dienstag 02 November 2010, 16:57:38 schrieb Benjamin Griese:
Hello Ralf,
nice to know that someone from Novell is reading here, too.
Currently I have opened up a Service Request regarding this topic at Novells Suport Center and pointed that out as a Feature Request but also as problem I and other people have and are lookinf for a workaround.
The feature request is regarding build the overlays as dynamic modules, I guess? Yes that's something we are looking into as well. But for this special SSS/VLV issue there is already a fix in CVS which I we will most probably include in our packages. Changing from static overlays to dynamic overlays is unlikely to happen during the SLES11 timeframe I think (but we are getting off topic ...)
Too bad I am really low experienced in building complex ACLs to filter stuff like this, maybe someone else is able to help us (James and me) to workaround that problem.
Something like this should work:
access to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none access to dn.base="" attrs=supportedControl val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none
I just found out however that there seems to be a bug in the ACL code when the above ACL appear as the first ACL in the configuration :(. I am still trying to track down that problem. So please make sure to have another ACL before them (one that doesn't apply to the "supportedControl" Attribute of course).
I'll give it a shot and let you know if it's working or not. :)
Good luck.
Ralf
-- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Am Mittwoch 03 November 2010, 09:52:26 schrieb Benjamin Griese:
Hello Ralf,
[..]
In the meantime I set the ACL, but unfortunatly it didn't help solving the problem, you may take a look at my example:
DN: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=ldapadm,dc=example,dc=de" write by dn="cn=proxyuser,ou=system,ou=people,dc=example,dc=de" read by anonymous auth by self write by * none olcAccess: {1} to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none olcAccess: {2} to dn.base="" attrs=supportedControl val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none olcAccess: {3}to dn.base="" by * read olcAccess: {4}to * by dn="cn=ldapadm,dc=example,dc=de" write by * read
If I remember right {4} is not opening up the access when it is explicitly denied in the ACLs {1} & {2}, am I right?
Yes, you are right.
But I'm not sure if this is the right place for this kind of ACL, cn=config instead should be wrong too I guess.
It has to be in the global ACL, i.e. you have to add it to olcDatabase={-1}frontend,cn=config.
Bye, Benjamin.
[..]
Ralf
Because my last post was hung up from the original thread.
===========================================
Hello Ralf,
thank you very much for your help! :) In the first place it didn't work and I was sure you have tested the functionality, so I checked what I may have configured differently/wrong. So I checked my list of supportedControls which are presented to the clients:
ldapsearch -x -b "" -s base supportedControl
before: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12
This shows the list of supportedControls and the denied Controls were still visible.
To make it work I had to put olcAccess: {1}to dn.base="" by * read further down to olcAccess: {3}to dn.base="" by * read below the two denied Controls.
after: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12
After that the supportedControls weren't visible anymore when requesting the list.
Finally, my working frontend:
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="cn=subschema" by * read olcAccess: {1} to dn.base="" attrs=supportedControl val/objectIdentifierMatc h=1.2.840.113556.1.4.473 by * none olcAccess: {2} to dn.base="" attrs=supportedControl val/objectIdentifierMatc h=2.16.840.1.113730.3.4.9 by * none olcAccess: {3}to dn.base="" by * read olcAccess: {4}to attrs=userPassword,userPKCS12 by self write by * auth olcAccess: {5}to attrs=shadowLastChange by self write by * read olcAccess: {6}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcMonitoring: FALSE olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE
Now requesting passwd/group/sudoers/etc with the Solaris 10 native client works like a charm, to me its like "less is more". :)
Thanks to all of you who tried to help and fix the problem, especially Ralf and Dieter.
Have a nice day, Benjamin.
On Wed, Nov 3, 2010 at 12:07, Ralf Haferkamp rhafer@suse.de wrote:
Am Mittwoch 03 November 2010, 09:52:26 schrieb Benjamin Griese:
Hello Ralf,
[..]
In the meantime I set the ACL, but unfortunatly it didn't help solving the problem, you may take a look at my example:
DN: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=ldapadm,dc=example,dc=de" write by dn="cn=proxyuser,ou=system,ou=people,dc=example,dc=de" read by anonymous auth by self write by * none olcAccess: {1} to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none olcAccess: {2} to dn.base="" attrs=supportedControl val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none olcAccess: {3}to dn.base="" by * read olcAccess: {4}to * by dn="cn=ldapadm,dc=example,dc=de" write by * read
If I remember right {4} is not opening up the access when it is explicitly denied in the ACLs {1} & {2}, am I right?
Yes, you are right.
But I'm not sure if this is the right place for this kind of ACL, cn=config instead should be wrong too I guess.
It has to be in the global ACL, i.e. you have to add it to olcDatabase={-1}frontend,cn=config.
Bye, Benjamin.
[..]
Ralf
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Am Dienstag 02 November 2010, 18:03:56 schrieb Ralf Haferkamp:
Am Dienstag 02 November 2010, 16:57:38 schrieb Benjamin Griese:
[..]
Something like this should work:
access to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.473 by * none access to dn.base="" attrs=supportedControl val/objectIdentifierMatch=2.16.840.1.113730.3.4.9 by * none
I just found out however that there seems to be a bug in the ACL code when the above ACL appear as the first ACL in the configuration :(. I am still trying to track down that problem.
FYI, this is now ITS#6693.
So please make sure to have another ACL before them (one that doesn't apply to the "supportedControl" Attribute of course).
Ralf
Benjamin Griese der.darude@gmail.com writes:
Correction: -w <passwd> or -w - instead of -W
On Thu, Oct 28, 2010 at 15:02, Benjamin Griese der.darude@gmail.com wrote:
Hello Günther,
sorry for my late reply, I hate sun cluster panics after patching those beasts. :(
Here is the content of solaris_profile:
[...]
If I try to search with -x and -S uidnumber I get the same message that appears in the OpenLDAP logfile: # ldapsearch -v -x -S uidNumber -b dc=example,dc=de -h exampleldap01 -D cn=proxyuser,ou=system,ou=people,dc=example,dc=de -W '(uid=*)'
ldapsearch: started Thu Oct 28 12:25:50 2010 ldap_init( exampleldap01, 389 ) filter pattern: (uid=*) returning: ALL filter is: (uid=*) ldap_search: Inappropriate matching ldap_search: additional info: serverSort control: No ordering rule ldap_parse_sort_control: Requested LDAP control not found
Finally I still have no clue how to prevent the client from doing these kinds of searches. And I couldn't find any templates regarding the ldapclient on my test machine.
Any other clues or ideas?
Somehow it is out of topic, but I have no clue how or who initiated the sss control. Just to get correct sorted results, you may do ldapsearch -J 1.2.840.113556.1.4.473:true:uid:2.5.13.3 For more information on how to construct the key list see RFC-2891.
-Dieter
openldap-technical@openldap.org
-
Benjamin Griese -
Dieter Kluenter -
James Bagley Jr -
Ralf Haferkamp