[Freeipa-users] FreeIPA for AMM users management
Hi all. I'd like to use FreeIPA for AMM (advanced management module) user management using this instruction [1]. I enabled option use DNS for find LDAP servers and set root DN and Binding method w/ Login Credentials but cannot login with IPA credentials. Logs of dirsrv and kerberos are empty. DNS server works correctly. [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html -- Best regards, Pavel Zhukov mailto:pa...@zhukoff.net ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo not working
That's got me closer now, as I'm at least getting an error message on stdout: [root@fs1 etc]# more nslcd.conf binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me [root@fs1 etc]# sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [root@fs1 ~]# So I'm off to figure out where my credentials are wrong. Thanks again, Rob, Stephen Pavel. Bret On Wed, Oct 31, 2012 at 2:39 PM, Rob Crittenden rcrit...@redhat.com wrote: Bret Wortman wrote: [root@fs1 etc]# more /etc/ldap.conf sudoers_debug: 1 [root@fs1 etc]# ls -l /etc/ldap.conf -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf Where should I see the extra output? I've had this set since last Friday and I'm not seeing any difference. Move the contents of /etc/nslcd.conf to this file and add ldap to sudoers in /etc/nsswitch.conf. rob On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: F17. I think you want /etc/ldap.conf then. The easiest way to be sure the right file is being used is to add sudoers_debug 1 to the file. This will present a lot of extra output so you'll know the file is being read. rob On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages. I'll try switching to SSS and see what that gets me. What distro is this? If it is RHEL 6.3 then put the configuration into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are working on getting them fixed). rob On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com** wrote: On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: I'm pretty certain there's a painfully simple solution to this that I'm not seeing, but my current configuration isn't picking up the freeipa sudoer rule that I've set. /etc/nsswitch.conf specifies: sudoers:files ldap /etc/nslcd.conf contains: binddn uid=sudo,cn=sysaccounts,cn=___** ___etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me http://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me The sssd_DOMAIN.log file contains this when I try to sudo: snip The SSSD logs aren't showing anything wrong because they have nothing to do with the execution of the SUDO rules in this situation. All the SSSD is doing is verifying the authentication (when sudo prompts you for your password). The problem with the rule is most likely happening inside SUDO itself. When you specify 'sudoers: files, ldap' in nsswitch.conf, it's telling SUDO to use its own internal LDAP driver to look up the rules. So you need to check sudo logs to see what's happening (probably you will need to enable debug logging in /etc/sudo.conf). Recent versions of SUDO (1.8.6 and later) have support for setting 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0
Re: [Freeipa-users] Sudo not working
To close the loop: I did the following to clear the credential problem. I suspect that I hadn't properly run kinit before doing these steps the first time: -sh-4.2$ kinit Password for br...@wedgeofli.me: -sh-4.2$ sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [sudo] password for bretw: bretw is not in the sudoers file. This incident will be reported. -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ ldapsearch ou=SUDOers,dc=wedgeofli,dc=me SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ ldapsearch -D uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password ou=SUDOers,dc=wedgeofli,dc=me ldap_bind: Invalid credentials (49) -sh-4.2$ ldappasswd -Y GSSAPI -S -h fs1.wedgeofli.meuid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me New password: Re-enter new password: SASL/GSSAPI authentication started SASL username: br...@wedgeofli.me SASL SSF: 56 SASL data security layer installed. -sh-4.2$ ldapsearch -D uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ sudo su - [sudo] password for bretw: [root@fs1 ~]# On Thu, Nov 1, 2012 at 7:58 AM, Bret Wortman bret.wort...@damascusgrp.comwrote: That's got me closer now, as I'm at least getting an error message on stdout: [root@fs1 etc]# more nslcd.conf binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me [root@fs1 etc]# sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [root@fs1 ~]# So I'm off to figure out where my credentials are wrong. Thanks again, Rob, Stephen Pavel. Bret On Wed, Oct 31, 2012 at 2:39 PM, Rob Crittenden rcrit...@redhat.comwrote: Bret Wortman wrote: [root@fs1 etc]# more /etc/ldap.conf sudoers_debug: 1 [root@fs1 etc]# ls -l /etc/ldap.conf -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf Where should I see the extra output? I've had this set since last Friday and I'm not seeing any difference. Move the contents of /etc/nslcd.conf to this file and add ldap to sudoers in /etc/nsswitch.conf. rob On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: F17. I think you want /etc/ldap.conf then. The easiest way to be sure the right file is being used is to add sudoers_debug 1 to the file. This will present a lot of extra output so you'll know the file is being read. rob On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages. I'll try switching to SSS and see what that gets me. What distro is this? If it is RHEL 6.3 then put the configuration into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are working on getting them fixed). rob On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com mailto:sgall...@redhat.com** wrote: On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: I'm pretty certain there's a painfully simple solution to this that I'm not seeing, but my current configuration isn't picking up the freeipa sudoer rule that I've set. /etc/nsswitch.conf specifies: sudoers:files ldap
Re: [Freeipa-users] Sudo not working
On 11/01/2012 08:26 AM, Bret Wortman wrote: To close the loop: I did the following to clear the credential problem. I suspect that I hadn't properly run kinit before doing these steps the first time: -sh-4.2$ kinit Password for br...@wedgeofli.me mailto:br...@wedgeofli.me: -sh-4.2$ sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [sudo] password for bretw: bretw is not in the sudoers file. This incident will be reported. This seems to suggest that it tries to use sudoers file instead of LDAP. -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 If you used kinit you then can use -Y GSSAPI to use kerberos credential for the authentication. -sh-4.2$ ldapsearch ou=SUDOers,dc=wedgeofli,dc=me SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: -sh-4.2$ ldapsearch -x ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ ldapsearch -D uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password ou=SUDOers,dc=wedgeofli,dc=me ldap_bind: Invalid credentials (49) -sh-4.2$ ldappasswd -Y GSSAPI -S -h fs1.wedgeofli.me http://fs1.wedgeofli.me uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me New password: Re-enter new password: SASL/GSSAPI authentication started SASL username: br...@wedgeofli.me mailto:br...@wedgeofli.me SASL SSF: 56 SASL data security layer installed. -sh-4.2$ ldapsearch -D uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me -w password ou=SUDOers,dc=wedgeofli,dc=me # extended LDIF # # LDAPv3 # base dc=wedgeofli,dc=me (default) with scope subtree # filter: ou=SUDOers,dc=wedgeofli,dc=me # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 -sh-4.2$ sudo su - [sudo] password for bretw: [root@fs1 ~]# On Thu, Nov 1, 2012 at 7:58 AM, Bret Wortman bret.wort...@damascusgrp.com mailto:bret.wort...@damascusgrp.com wrote: That's got me closer now, as I'm at least getting an error message on stdout: [root@fs1 etc]# more nslcd.conf binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me http://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me [root@fs1 etc]# sudo su - sudo: ldap_sasl_bind_s(): Invalid credentials [root@fs1 ~]# So I'm off to figure out where my credentials are wrong. Thanks again, Rob, Stephen Pavel. Bret On Wed, Oct 31, 2012 at 2:39 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: [root@fs1 etc]# more /etc/ldap.conf sudoers_debug: 1 [root@fs1 etc]# ls -l /etc/ldap.conf -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf Where should I see the extra output? I've had this set since last Friday and I'm not seeing any difference. Move the contents of /etc/nslcd.conf to this file and add ldap to sudoers in /etc/nsswitch.conf. rob On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: F17. I think you want /etc/ldap.conf then. The easiest way to be sure the right file is being used is to add sudoers_debug 1 to the file. This will present a lot of extra output so you'll know the file is being read. rob On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages.
Re: [Freeipa-users] FreeIPA for AMM users management
On 11/01/2012 12:27 AM, Pavel Zhukov wrote: Hi all. I'd like to use FreeIPA for AMM (advanced management module) user management using this instruction [1]. I enabled option use DNS for find LDAP servers and set root DN and Binding method w/ Login Credentials but cannot login with IPA credentials. Logs of dirsrv and kerberos are empty. DNS server works correctly. [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html Firewall? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA for AMM users management
No, because authentication of Alfresco and RHEV users works fine for example. -- Best regards, Pavel Zhukov mailto:pa...@zhukoff.net On Thu, 01 Nov 2012, Dmitri Pal wrote: On 11/01/2012 12:27 AM, Pavel Zhukov wrote: Hi all. I'd like to use FreeIPA for AMM (advanced management module) user management using this instruction [1]. I enabled option use DNS for find LDAP servers and set root DN and Binding method w/ Login Credentials but cannot login with IPA credentials. Logs of dirsrv and kerberos are empty. DNS server works correctly. [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html Firewall? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA for AMM users management
On Thu, 2012-11-01 at 08:27 +0400, Pavel Zhukov wrote: Hi all. I'd like to use FreeIPA for AMM (advanced management module) user management using this instruction [1]. I enabled option use DNS for find LDAP servers and set root DN and Binding method w/ Login Credentials but cannot login with IPA credentials. Logs of dirsrv and kerberos are empty. DNS server works correctly. [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html I am not sure that bind w/ Login Credentials will work properly if they assume Active Directory. AD has a non standard authentication method that allows to not use a DN to identify a user. We do not support that authentication method. However you should at least see the bind attempt and an error message in the dirsrv access log. If you do not see that then something else is broken before a bind is even attempted, perhaps DNS discovery ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA for AMM users management
On Thu, 2012-11-01 at 15:55 -0400, Simo Sorce wrote: On Thu, 2012-11-01 at 08:27 +0400, Pavel Zhukov wrote: Hi all. I'd like to use FreeIPA for AMM (advanced management module) user management using this instruction [1]. I enabled option use DNS for find LDAP servers and set root DN and Binding method w/ Login Credentials but cannot login with IPA credentials. Logs of dirsrv and kerberos are empty. DNS server works correctly. [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html I am not sure that bind w/ Login Credentials will work properly if they assume Active Directory. AD has a non standard authentication method that allows to not use a DN to identify a user. We do not support that authentication method. However you should at least see the bind attempt and an error message in the dirsrv access log. If you do not see that then something else is broken before a bind is even attempted, perhaps DNS discovery ? Ah btw, have you enabled SSL ? FreeIPA enforces that simple binds be done on an encrypted channel.If you try to bind with plain text credentials on an unencrypted channel FreeIPA simply returns an error. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA for AMM users management
On Thu, 2012-11-01 at 17:09 -0400, Simo Sorce wrote: On Thu, 2012-11-01 at 15:55 -0400, Simo Sorce wrote: On Thu, 2012-11-01 at 08:27 +0400, Pavel Zhukov wrote: Hi all. I'd like to use FreeIPA for AMM (advanced management module) user management using this instruction [1]. I enabled option use DNS for find LDAP servers and set root DN and Binding method w/ Login Credentials but cannot login with IPA credentials. Logs of dirsrv and kerberos are empty. DNS server works correctly. [1] - http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp?topic=/com.ibm.bladecenter.advmgtmod.doc/kp1bb_bc_mmug_configldap_ADrolebasedauthen.html I am not sure that bind w/ Login Credentials will work properly if they assume Active Directory. AD has a non standard authentication method that allows to not use a DN to identify a user. We do not support that authentication method. However you should at least see the bind attempt and an error message in the dirsrv access log. If you do not see that then something else is broken before a bind is even attempted, perhaps DNS discovery ? Ah btw, have you enabled SSL ? FreeIPA enforces that simple binds be done on an encrypted channel.If you try to bind with plain text credentials on an unencrypted channel FreeIPA simply returns an error. Uhmm sorry this is not true for binds, it is true only for password changes (and SSSD enforces auth only via SSL, but it is client side enforcement). Sorry for the noise. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Process open FD table is full.
Have any folks run into this: PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.) From the dirsrv logs. It appears that this may have been what killed IPA in total on one server for me last night. I can't turn up anything via Google. After a restart of all the IPA processes everything started working again. I have looked into FD limits on the system and it doesn't seem like that is a likely cause. Found info here: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html This is on a RHEL 6.3 system fully updated. Any ideas? -Erinn signature.asc Description: OpenPGP digital signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Process open FD table is full.
On 11/01/2012 04:15 PM, Erinn Looney-Triggs wrote: Have any folks run into this: PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.) From the dirsrv logs. It appears that this may have been what killed IPA in total on one server for me last night. I can't turn up anything via Google. After a restart of all the IPA processes everything started working again. I have looked into FD limits on the system and it doesn't seem like that is a likely cause. Found info here: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html This is on a RHEL 6.3 system fully updated. Any ideas? https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Performance_Tuning_Guide/system-tuning.html#file-descriptors -Erinn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Process open FD table is full.
On 11/01/2012 06:57 PM, Erinn Looney-Triggs wrote: On 11/01/12 16:47, Rich Megginson wrote: On 11/01/2012 04:15 PM, Erinn Looney-Triggs wrote: Have any folks run into this: PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.) From the dirsrv logs. It appears that this may have been what killed IPA in total on one server for me last night. I can't turn up anything via Google. After a restart of all the IPA processes everything started working again. I have looked into FD limits on the system and it doesn't seem like that is a likely cause. Found info here: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html This is on a RHEL 6.3 system fully updated. Any ideas? https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Performance_Tuning_Guide/system-tuning.html#file-descriptors Yeah thanks but to my untrained eye it doesn't exactly fit: erinn@ipa ~ $ cat /proc/sys/fs/file-max 1199770 erinn@ipa ~ $ cat /etc/security/limits.conf dirsrv - nofile 8192 and, session required pam_limits.so in system-auth Did you look at section 3.3.2. Setting Directory Server File Descriptor Values This was all there before and yet I hit on that problem. Am I reading things incorrectly or not understanding them, I have a very small environment (~40 systems) and it doesn't seem like I should be having this problem. That does seem strange. -Erinn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
