Re: [389-users] Greedy PAM
From: 389-users-boun...@lists.fedoraproject.org [389-users-boun...@lists.fedoraproject.org] on behalf of Daniel Maher [dma+389us...@witbe.net] Sent: 15 October 2010 16:12 To: 389-users@lists.fedoraproject.org Subject: Re: [389-users] Greedy PAM On 10/15/2010 04:57 PM, Gerrard Geldenhuis wrote: Is there a way to dynamically have search basis when queries for certain data is done. Yes. How do you configure clients to be more selective when doing searches against a ldap directory. It depends entirely on the software doing the query. Here's an example from one of my Apache HTTPd configs : AuthLDAPURL ldap://server/ou=People,dc=franceix,dc=net?uid??(|(gidNumber=1)(gidNumber=11000)) Thanks, I have addded the following filters for PAM in /etc/ldap.conf nss_base_passwd ou=people,dc=mycompany?sub nss_base_group ou=Groups,dc=mycompany?sub nss_base_group ou=PrivateGroups,dc=mycompany?sub nss_base_group ou=SystemGroups,dc=mycompany?sub It works kind of but what I don't understand is that when a client authenticates against the directory server I see a ldapsearch request in wireshark for every single user. I am not sure if this a misconfiguration on my side or if PAM_LDAP is being greedy/lazy/buggy or where else the problem lies. I see a succesfull result for every ldap search request in LDAP so I am not sure why every user would need to be queried if only one user needs to authenticate. We use a seperate user to speak to the Directory specified in /etc/ldap.conf. I am not sure if that would make a difference. binddn uid=SysAuth,ou=Service Accounts,dc=mycompany Any thoughts would be appreciated and suggestions for a nice tool to analyze LDAP conversations would be much appreciated. I am playing with dsniff and netsniff-ng. 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
Re: [389-users] Safeguarding against to many established connections
On 10/19/2010 12:11 PM, Gerrard Geldenhuis wrote: Hi We have recently seen an issue were a single client opened up more than 800 established connections to our directory server. The client did have the proper settings configured and should have closed connections but it did'nt. Is there a way to limit the amount of connections per client or close connections from the server side after a certain period? Without just making the amount of connections ridicuosly high on the directory server how can you safeguard against rogue clients. Our client setting is as follows: idle_timelimit 5 timelimit 10 bind_timelimit 5 We were unable to log into client and it had file system issues so we could not do any further analyses there. I suspect that solutions to this problem probably falls outside of what can be configured in 389? While it's not a 389-specific suggestion, iptables could easily solve this problem for you across the board. :) -- Daniel Maher dma + 389users AT witbe DOT net -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Safeguarding against to many established connections
- Missatge original - On 10/19/2010 12:11 PM, Gerrard Geldenhuis wrote: Hi We have recently seen an issue were a single client opened up more than 800 established connections to our directory server. The client did have the proper settings configured and should have closed connections but it did'nt. Is there a way to limit the amount of connections per client or close connections from the server side after a certain period? Without just making the amount of connections ridicuosly high on the directory server how can you safeguard against rogue clients. Our client setting is as follows: idle_timelimit 5 timelimit 10 bind_timelimit 5 We were unable to log into client and it had file system issues so we could not do any further analyses there. I suspect that solutions to this problem probably falls outside of what can be configured in 389? While it's not a 389-specific suggestion, iptables could easily solve this problem for you across the board. :) there's also a setting to close idle connections after X seconds. is somewhere in the 389 console, i can't remember now exactly. abosch -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Safeguarding against to many established connections
From: 389-users-boun...@lists.fedoraproject.org [389-users-boun...@lists.fedoraproject.org] on behalf of Angel Bosch Mora [angbo...@conselldemallorca.net] Sent: 19 October 2010 11:28 To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] Safeguarding against to many established connections - Missatge original - On 10/19/2010 12:11 PM, Gerrard Geldenhuis wrote: Hi We have recently seen an issue were a single client opened up more than 800 established connections to our directory server. The client did have the proper settings configured and should have closed connections but it did'nt. Is there a way to limit the amount of connections per client or close connections from the server side after a certain period? Without just making the amount of connections ridicuosly high on the directory server how can you safeguard against rogue clients. Our client setting is as follows: idle_timelimit 5 timelimit 10 bind_timelimit 5 We were unable to log into client and it had file system issues so we could not do any further analyses there. I suspect that solutions to this problem probably falls outside of v what can be configured in 389? While it's not a 389-specific suggestion, iptables could easily solve this problem for you across the board. :) there's also a setting to close idle connections after X seconds. is somewhere in the 389 console, i can't remember now exactly. Thanks! I little bit more searching have revealed the following settings which I would like to try: 3.1.1.85. nsslapd-outbound-ldap-io-timeout This attribute limits the I/O wait time for all outbound LDAP connections. The default is 30 milliseconds (5 minutes). A value of 0 means that the server does not impose a limit on I/O wait time. 4.5.2.8. nsConnectionLife This attribute specifies connection lifetime. Connections between the database link and the remote server can be kept open for an unspecified time or closed after a specific period of time. It is faster to keep the connections open, but it uses more resources. When the value is 0 and a list of failover servers is provided in the nsFarmServerURL attribute, the main server is never contacted after failover to the alternate server. 4.5.2.9. nsOperationConnectionsLimit This attribute shows the maximum number of LDAP connections the database link establishes with the remote server. What is not perfectly clear to me though is does this apply to all connections other masters, consumers and 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
Re: [389-users] Safeguarding against to many established connections
From: 389-users-boun...@lists.fedoraproject.org [389-users-boun...@lists.fedoraproject.org] on behalf of Daniel Maher [dma+389us...@witbe.net] Sent: 19 October 2010 11:16 To: 389-users@lists.fedoraproject.org Subject: Re: [389-users] Safeguarding against to many established connections On 10/19/2010 12:11 PM, Gerrard Geldenhuis wrote: Hi We have recently seen an issue were a single client opened up more than 800 established connections to our directory server. The client did have the proper settings configured and should have closed connections but it did'nt. Is there a way to limit the amount of connections per client or close connections from the server side after a certain period? Without just making the amount of connections ridicuosly high on the directory server how can you safeguard against rogue clients. Our client setting is as follows: idle_timelimit 5 timelimit 10 bind_timelimit 5 We were unable to log into client and it had file system issues so we could not do any further analyses there. I suspect that solutions to this problem probably falls outside of what can be configured in 389? While it's not a 389-specific suggestion, iptables could easily solve this problem for you across the board. :) I would be keen on such a solution but from a company point of view it is non-standard so I would need to do a bit of convincing and/arm twisting. 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
Re: [389-users] Safeguarding against to many established connections
Hi, you may be interested in the following threads with some solutions : http://lists.fedoraproject.org/pipermail/389-users/2010-September/012149.html http://lists.fedoraproject.org/pipermail/389-users/2009-February/009062.html @+ 2010/10/19 Gerrard Geldenhuis gerrard.geldenh...@betfair.com I suspect that solutions to this problem probably falls outside of what can be configured in 389? While it's not a 389-specific suggestion, iptables could easily solve this problem for you across the board. :) Do you have thoughts on criteria for iptables... how do you differentiate between 800 healthy connections and 800 duff ones if both have an ESTABLISHED state? Do you just assume it will never be that much and limit accordingly or do you do time limit to say that connections should never be maintained longer than x minutes and require clients to re-establish connections? 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
[389-users] difficulties upgrading from 1.2.5 to 1.2.6.1-2
Hi Guys, I'm having problems upgrading from 1.2.5 Here's what I did: # yum upgrade 389-ds-base -runs fine # setup-ds-admin.pl -u -error encountered: The server 'ldap://myldapserver.com:389/o=NetscapeRoot' is not reachable. Error: unknown error It turns out that the 389-DS is not running because of these errors in its error log: 389-Directory/1.2.6.1 B2010.272.2313 myldapserver.com:389 (/etc/dirsrv/slapd-myldapserver) [20/Oct/2010:14:35:41 +1000] - 389-Directory/1.2.6.1 B2010.272.2313 starting up [20/Oct/2010:14:35:42 +1000] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [20/Oct/2010:14:35:42 +1000] - nsslapd-subtree-rename-switch is on, while the instance userRoot is in the DN format. Please run dn2rdn to convert the database format. [20/Oct/2010:14:35:42 +1000] - nsslapd-subtree-rename-switch is on, while the instance Root1 is in the DN format. Please run dn2rdn to convert the database format. [20/Oct/2010:14:35:42 +1000] - nsslapd-subtree-rename-switch is on, while the instance Root2 is in the DN format. Please run dn2rdn to convert the database format. [20/Oct/2010:14:35:42 +1000] - nsslapd-subtree-rename-switch is on, while the instance Root3 is in the DN format. Please run dn2rdn to convert the database format. [20/Oct/2010:14:35:42 +1000] - nsslapd-subtree-rename-switch is on, while the instance NetscapeRoot is in the DN format. Please run dn2rdn to convert the database format. [20/Oct/2010:14:35:42 +1000] - nsslapd-subtree-rename-switch is on, while the instance Root4 is in the DN format. Please run dn2rdn to convert the database format. [20/Oct/2010:14:35:42 +1000] - start: Failed to start databases, err=-1 Unknown error: -1 [20/Oct/2010:14:35:42 +1000] - Failed to start database plugin ldbm database [20/Oct/2010:14:35:42 +1000] - WARNING: ldbm instance userRoot already exists [20/Oct/2010:14:35:42 +1000] - WARNING: ldbm instance Root1 already exists [20/Oct/2010:14:35:42 +1000] - WARNING: ldbm instance Root2 already exists [20/Oct/2010:14:35:42 +1000] - WARNING: ldbm instance Root3 already exists [20/Oct/2010:14:35:42 +1000] - WARNING: ldbm instance NetscapeRoot already exists [20/Oct/2010:14:35:42 +1000] - WARNING: ldbm instance Root4 already exists [20/Oct/2010:14:35:42 +1000] binder-based resource limits - nsLookThroughLimit: parameter error (slapi_reslimit_register() already registered) [20/Oct/2010:14:35:42 +1000] - start: Resource limit registration failed [20/Oct/2010:14:35:42 +1000] - Failed to start database plugin ldbm database [20/Oct/2010:14:35:42 +1000] - Error: Failed to resolve plugin dependencies [20/Oct/2010:14:35:42 +1000] - Error: preoperation plugin 7-bit check is not started [20/Oct/2010:14:35:42 +1000] - Error: accesscontrol plugin ACL Plugin is not started [20/Oct/2010:14:35:42 +1000] - Error: preoperation plugin ACL preoperation is not started [20/Oct/2010:14:35:42 +1000] - Error: object plugin Class of Service is not started [20/Oct/2010:14:35:42 +1000] - Error: preoperation plugin deref is not started [20/Oct/2010:14:35:42 +1000] - Error: preoperation plugin HTTP Client is not started [20/Oct/2010:14:35:42 +1000] - Error: database plugin ldbm database is not started [20/Oct/2010:14:35:42 +1000] - Error: object plugin Legacy Replication Plugin is not started [20/Oct/2010:14:35:42 +1000] - Error: preoperation plugin Linked Attributes is not started [20/Oct/2010:14:35:42 +1000] - Error: object plugin Multimaster Replication Plugin is not started [20/Oct/2010:14:35:42 +1000] - Error: object plugin Roles Plugin is not started [20/Oct/2010:14:35:42 +1000] - Error: preoperation plugin Simple Kerberos 5 Auth is not started [20/Oct/2010:14:35:42 +1000] - Error: object plugin Views is not started - I wanted to do the dn2rdn or just switch off the subtree-rename- switch, so... - I looked at the instance's dse.ldif and I can't find the: dn: cn=config,cn=ldbm database,cn=plugins,cn=config [...] nsslapd-subtree-rename-switch: on - But nsslapd-subtree-rename-switch exists is in this file: /usr/ share/dirsrv/data/template-dse.ldif. I tried changing the value to 'off' but I still got the same errors. - I also can't find the the dn2rdn tool in the slapd instance directory. I did a locate and only found it here: /usr/share/dirsrv/ script-templates/template-dn2rdn -So I got really confused and thought maybe I should do this: # setup-ds.pl -u -d = = = = = = This program will update the 389 Directory Server. It is recommended that you have root privilege to perform the update. Tips for using this program: - Press Enter to choose the default and go to the next screen - Type Control-B or the word back then Enter to go back to the previous screen - Type Control-C to cancel the update Would you like to continue with update? [yes]: = = =
