Re: [Freeipa-users] Timeout (?) issues
SRV records were missing for _ldaps_tcp. I added them in for the IPA servers and that knocked out some of the errors, but there are still a lot. I suspect these boxes are overloaded with bad dns queries (probably due to something I've messed up.) Any help would be appreciated, but I'm opening a RH ticket. Thanks, --Jason On Thu, Sep 19, 2013 at 1:57 PM, KodaK sako...@gmail.com wrote: Well, this is awkward: [root@slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l 5453936 [root@slpidml01 slapd-UNIX-xxx-COM]# On Thu, Sep 19, 2013 at 1:48 PM, KodaK sako...@gmail.com wrote: Thanks. I've been running that against my logs, and this has to be abnormal: err=32 129274No Such Object err=0 10952Successful Operations err=14 536SASL Bind in Progress err=53 39Unwilling To Perform err=493Invalid Credentials (Bad Password) I'm still trying to figure out why there are so many error 32s. Are there any usual suspects I should know about? (That's just the current access log, btw.) On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson rmegg...@redhat.comwrote: On 09/16/2013 07:57 PM, Dmitri Pal wrote: On 09/16/2013 12:02 PM, KodaK wrote: Yet another AIX related problem: The AIX LDAP client is called secldapclntd (sure, they could make it more awkward, but the budget ran out.) I'm running into the issue detailed here: http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 If an LDAP server fails to answer an LDAP query, secldapclntd caches the non-answered query negatively. This may happen if the LDAP server is down for example. After the LDAP server is back again secldapclntd will use the negative cache entry and the application initiating the original query will still fail until the cache entry expires. IBM is working on porting the fix to our specific TL and SP levels. What I'm concerned with here, though, is *why* is it timing out? I don't know what the current timeout values are (AIX sucks, etc.) I don't see timeout issues on my Linux boxes, which leads me to believe that either the sssd timouts are longer or that sssd is just more robust when dealing with timeouts. I believe I'm seeing similar behavior with LDAP sudo on AIX as well, because I occasionally have to re-run sudo commands because they initially fail (and I know I'm using the right passwords.) However, sudo doesn't appear to have a cache (or it handles caching better.) Does anyone have any troubleshooting suggestions? Any general speed things up suggestions on the IPA side? Thanks, --Jason -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users Is the server FreeIPA? Can see in the server logs what is actually happening is it the server that really takes time or there is a network connectivity issue or FW is dropping packets? I would really start with the server side logs. As far as 389 goes, run logconv.pl against the access logs in /var/log/dirsrv/slapd-DOMAIN-COM -- 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 listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Timeout (?) issues
Well, this is awkward: [root@slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l 5453936 [root@slpidml01 slapd-UNIX-xxx-COM]# On Thu, Sep 19, 2013 at 1:48 PM, KodaK sako...@gmail.com wrote: Thanks. I've been running that against my logs, and this has to be abnormal: err=32 129274No Such Object err=0 10952Successful Operations err=14 536SASL Bind in Progress err=53 39Unwilling To Perform err=493Invalid Credentials (Bad Password) I'm still trying to figure out why there are so many error 32s. Are there any usual suspects I should know about? (That's just the current access log, btw.) On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson rmegg...@redhat.comwrote: On 09/16/2013 07:57 PM, Dmitri Pal wrote: On 09/16/2013 12:02 PM, KodaK wrote: Yet another AIX related problem: The AIX LDAP client is called secldapclntd (sure, they could make it more awkward, but the budget ran out.) I'm running into the issue detailed here: http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 If an LDAP server fails to answer an LDAP query, secldapclntd caches the non-answered query negatively. This may happen if the LDAP server is down for example. After the LDAP server is back again secldapclntd will use the negative cache entry and the application initiating the original query will still fail until the cache entry expires. IBM is working on porting the fix to our specific TL and SP levels. What I'm concerned with here, though, is *why* is it timing out? I don't know what the current timeout values are (AIX sucks, etc.) I don't see timeout issues on my Linux boxes, which leads me to believe that either the sssd timouts are longer or that sssd is just more robust when dealing with timeouts. I believe I'm seeing similar behavior with LDAP sudo on AIX as well, because I occasionally have to re-run sudo commands because they initially fail (and I know I'm using the right passwords.) However, sudo doesn't appear to have a cache (or it handles caching better.) Does anyone have any troubleshooting suggestions? Any general speed things up suggestions on the IPA side? Thanks, --Jason -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users Is the server FreeIPA? Can see in the server logs what is actually happening is it the server that really takes time or there is a network connectivity issue or FW is dropping packets? I would really start with the server side logs. As far as 389 goes, run logconv.pl against the access logs in /var/log/dirsrv/slapd-DOMAIN-COM -- 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 listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replication causing long etimes
Terry, did you ever get to the bottom of this? I appear to be having a similar issue with the same version of IPA. On Wed, Sep 4, 2013 at 1:18 PM, Terry Soucy tso...@salesforce.com wrote: I am experiencing some long execution times, and I'm wondering if anyone can give me some insight. We are running FreeIPA 3.0.0-26 on Redhat 6.1. We have multimaster replication running among 4 hosts. We have approv 100 users, 25 usergroups and hostgroups, and approx 2000 hosts in a single domain. We noticed that some DNS queries were timing out periodically. When I investigated further, I found several of the DNS requests in the access log [04/Sep/2013:13:42:24 -0300] conn=122491 op=3888679 SRCH base=idnsName=compute- 1.amazonaws.com,idnsname=prod.ca2.example.com,cn=dns,dc=example,dc=com scope=0 filter= (objectClass=idnsRecord) attrs=ALL [04/Sep/2013:13:42:44 -0300] conn=122491 op=3888679 RESULT err=32 tag=101 nentri es=0 etime=20 There are a lot of those, as expected, since we first noticed this issue with DNS. Then I found this ... [04/Sep/2013:13:42:23 -0300] conn=368561 op=9 EXT oid=2.16.840.1.113730.3.5.5 name=Netscape Replication End Session [04/Sep/2013:13:42:44 -0300] conn=368561 op=9 RESULT err=0 tag=120 nentries=0 etime=22 and lots of this ... [04/Sep/2013:13:42:26 -0300] conn=368604 op=0 BIND dn= method=sasl version=3 mech=GSSAPI [04/Sep/2013:13:42:44 -0300] conn=368604 op=0 RESULT err=14 tag=97 nentries=0 etime=18, SASL bind in progress So, is my SASL bind causing the replication to go long, or is the replication taking a long time and causing the hang? Is there a way I can see the details of the replication? There is not a lot of changes going on that require replication with regards to dns, users, hosts, etc, so I'm not sure why it would take so long. Also, can I remove the SASL bind and just add a replication user to the dse.ldif to remove the requirement for kerberos for replication? Terry -- Terry Soucy - Systems Engineer Salesforce MarketingCloud - http://www.salesforce.com (o) 506.631.7445 (c) 506.609.3247 | (e) tso...@salesforce.com ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Timeout (?) issues
I didn't realize that DNS created one connection. I thought it was one connection spanning several days. On Thu, Sep 19, 2013 at 2:51 PM, Rich Megginson rmegg...@redhat.com wrote: On 09/19/2013 12:57 PM, KodaK wrote: Well, this is awkward: [root@slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l 5453936 [root@slpidml01 slapd-UNIX-xxx-COM]# Why is it awkward? On Thu, Sep 19, 2013 at 1:48 PM, KodaK sako...@gmail.com wrote: Thanks. I've been running that against my logs, and this has to be abnormal: err=32 129274No Such Object err=0 10952Successful Operations err=14 536SASL Bind in Progress err=53 39Unwilling To Perform err=493Invalid Credentials (Bad Password) I'm still trying to figure out why there are so many error 32s. Are there any usual suspects I should know about? (That's just the current access log, btw.) On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson rmegg...@redhat.comwrote: On 09/16/2013 07:57 PM, Dmitri Pal wrote: On 09/16/2013 12:02 PM, KodaK wrote: Yet another AIX related problem: The AIX LDAP client is called secldapclntd (sure, they could make it more awkward, but the budget ran out.) I'm running into the issue detailed here: http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 If an LDAP server fails to answer an LDAP query, secldapclntd caches the non-answered query negatively. This may happen if the LDAP server is down for example. After the LDAP server is back again secldapclntd will use the negative cache entry and the application initiating the original query will still fail until the cache entry expires. IBM is working on porting the fix to our specific TL and SP levels. What I'm concerned with here, though, is *why* is it timing out? I don't know what the current timeout values are (AIX sucks, etc.) I don't see timeout issues on my Linux boxes, which leads me to believe that either the sssd timouts are longer or that sssd is just more robust when dealing with timeouts. I believe I'm seeing similar behavior with LDAP sudo on AIX as well, because I occasionally have to re-run sudo commands because they initially fail (and I know I'm using the right passwords.) However, sudo doesn't appear to have a cache (or it handles caching better.) Does anyone have any troubleshooting suggestions? Any general speed things up suggestions on the IPA side? Thanks, --Jason -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users Is the server FreeIPA? Can see in the server logs what is actually happening is it the server that really takes time or there is a network connectivity issue or FW is dropping packets? I would really start with the server side logs. As far as 389 goes, run logconv.pl against the access logs in /var/log/dirsrv/slapd-DOMAIN-COM -- 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 listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Timeout (?) issues
On 09/19/2013 12:57 PM, KodaK wrote: Well, this is awkward: [root@slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l 5453936 [root@slpidml01 slapd-UNIX-xxx-COM]# Why is it awkward? On Thu, Sep 19, 2013 at 1:48 PM, KodaK sako...@gmail.com mailto:sako...@gmail.com wrote: Thanks. I've been running that against my logs, and this has to be abnormal: err=32 129274No Such Object err=0 10952Successful Operations err=14 536SASL Bind in Progress err=53 39Unwilling To Perform err=493Invalid Credentials (Bad Password) I'm still trying to figure out why there are so many error 32s. Are there any usual suspects I should know about? (That's just the current access log, btw.) On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: On 09/16/2013 07:57 PM, Dmitri Pal wrote: On 09/16/2013 12:02 PM, KodaK wrote: Yet another AIX related problem: The AIX LDAP client is called secldapclntd (sure, they could make it more awkward, but the budget ran out.) I'm running into the issue detailed here: http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 If an LDAP server fails to answer an LDAP query, secldapclntd caches the non-answered query negatively. This may happen if the LDAP server is down for example. After the LDAP server is back again secldapclntd will use the negative cache entry and the application initiating the original query will still fail until the cache entry expires. IBM is working on porting the fix to our specific TL and SP levels. What I'm concerned with here, though, is *why* is it timing out? I don't know what the current timeout values are (AIX sucks, etc.) I don't see timeout issues on my Linux boxes, which leads me to believe that either the sssd timouts are longer or that sssd is just more robust when dealing with timeouts. I believe I'm seeing similar behavior with LDAP sudo on AIX as well, because I occasionally have to re-run sudo commands because they initially fail (and I know I'm using the right passwords.) However, sudo doesn't appear to have a cache (or it handles caching better.) Does anyone have any troubleshooting suggestions? Any general speed things up suggestions on the IPA side? Thanks, --Jason -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Is the server FreeIPA? Can see in the server logs what is actually happening is it the server that really takes time or there is a network connectivity issue or FW is dropping packets? I would really start with the server side logs. As far as 389 goes, run logconv.pl http://logconv.pl against the access logs in /var/log/dirsrv/slapd-DOMAIN-COM -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Timeout (?) issues
This is ridiculous, right? IPA server 1: # for i in $(ls access*); do echo -n $i:\ ;grep err=32 $i | wc -l; done access: 248478 access.20130916-043207: 302774 access.20130916-123642: 272572 access.20130916-201516: 294308 access.20130917-081053: 295060 access.20130917-144559: 284498 access.20130917-231435: 281035 access.20130918-091611: 291165 access.20130918-154945: 275792 access.20130919-014322: 296113 IPA server 2: access: 4313 access.20130909-200216: 4023 access.20130910-200229: 4161 access.20130911-200239: 4182 access.20130912-200249: 5069 access.20130913-200258: 3833 access.20130914-200313: 4208 access.20130915-200323: 4702 access.20130916-200332: 4532 IPA server 3: access: 802 access.20130910-080737: 3876 access.20130911-080748: 3902 access.20130912-080802: 3678 access.20130913-080810: 3765 access.20130914-080826: 3524 access.20130915-080907: 4142 access.20130916-080916: 4930 access.20130917-080926: 4769 access.20130918-081005: 2879 IPA server 4: access: 2812 access.20130910-003051: 4095 access.20130911-003105: 3623 access.20130912-003113: 3606 access.20130913-003125: 3581 access.20130914-003135: 3758 access.20130915-003150: 3935 access.20130916-003159: 4184 access.20130917-003210: 3859 access.20130918-003221: 5110 The vast majority of the err=32 messages are DNS entries. Here are some samples: [19/Sep/2013:18:19:51 -0500] conn=9 op=169764 SRCH base=idnsName=xxx.com ,idnsname=unix.xxx.com,cn=dns,dc=unix,dc=xxx,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [19/Sep/2013:18:19:51 -0500] conn=9 op=169764 RESULT err=32 tag=101 nentries=0 etime=0 [19/Sep/2013:18:19:51 -0500] conn=9 op=169774 SRCH base=idnsName= slpoxacl01.unix.xxx.com,idnsname=unix.xxx.com,cn=dns,dc=unix,dc=xxx,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [19/Sep/2013:18:19:51 -0500] conn=9 op=169774 RESULT err=32 tag=101 nentries=0 etime=0 [19/Sep/2013:18:19:51 -0500] conn=9 op=169770 SRCH base=idnsName= sla400q1.unix.xxx.com,idnsname=unix.xxx.com,cn=dns,dc=unix,dc=xxx,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [19/Sep/2013:18:19:51 -0500] conn=9 op=169770 RESULT err=32 tag=101 nentries=0 etime=0 [19/Sep/2013:18:19:51 -0500] conn=9 op=169772 SRCH base=idnsName= magellanhealth.com,idnsname=unix.magellanhealth.com,cn=dns,dc=unix,dc=magellanhealth,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [19/Sep/2013:18:19:51 -0500] conn=9 op=169772 RESULT err=32 tag=101 nentries=0 etime=0 So far today there are over half a million of these. That can't be right. On Thu, Sep 19, 2013 at 3:05 PM, KodaK sako...@gmail.com wrote: I didn't realize that DNS created one connection. I thought it was one connection spanning several days. On Thu, Sep 19, 2013 at 2:51 PM, Rich Megginson rmegg...@redhat.comwrote: On 09/19/2013 12:57 PM, KodaK wrote: Well, this is awkward: [root@slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l 5453936 [root@slpidml01 slapd-UNIX-xxx-COM]# Why is it awkward? On Thu, Sep 19, 2013 at 1:48 PM, KodaK sako...@gmail.com wrote: Thanks. I've been running that against my logs, and this has to be abnormal: err=32 129274No Such Object err=0 10952Successful Operations err=14 536SASL Bind in Progress err=53 39Unwilling To Perform err=493Invalid Credentials (Bad Password) I'm still trying to figure out why there are so many error 32s. Are there any usual suspects I should know about? (That's just the current access log, btw.) On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson rmegg...@redhat.comwrote: On 09/16/2013 07:57 PM, Dmitri Pal wrote: On 09/16/2013 12:02 PM, KodaK wrote: Yet another AIX related problem: The AIX LDAP client is called secldapclntd (sure, they could make it more awkward, but the budget ran out.) I'm running into the issue detailed here: http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 If an LDAP server fails to answer an LDAP query, secldapclntd caches the non-answered query negatively. This may happen if the LDAP server is down for example. After the LDAP server is back again secldapclntd will use the negative cache entry and the application initiating the original query will still fail until the cache entry expires. IBM is working on porting the fix to our specific TL and SP levels. What I'm concerned with here, though, is *why* is it timing out? I don't know what the current timeout values are (AIX sucks, etc.) I don't see timeout issues on my Linux boxes, which leads me to believe that either the sssd timouts are longer or that sssd is just more robust when dealing with timeouts. I believe I'm seeing similar behavior with LDAP sudo on AIX as well, because I occasionally have to re-run sudo commands because they initially fail (and I know I'm using the right passwords.) However, sudo doesn't appear to have a cache (or it handles caching
Re: [Freeipa-users] Timeout (?) issues
Thanks. I've been running that against my logs, and this has to be abnormal: err=32 129274No Such Object err=0 10952Successful Operations err=14 536SASL Bind in Progress err=53 39Unwilling To Perform err=493Invalid Credentials (Bad Password) I'm still trying to figure out why there are so many error 32s. Are there any usual suspects I should know about? (That's just the current access log, btw.) On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson rmegg...@redhat.com wrote: On 09/16/2013 07:57 PM, Dmitri Pal wrote: On 09/16/2013 12:02 PM, KodaK wrote: Yet another AIX related problem: The AIX LDAP client is called secldapclntd (sure, they could make it more awkward, but the budget ran out.) I'm running into the issue detailed here: http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 If an LDAP server fails to answer an LDAP query, secldapclntd caches the non-answered query negatively. This may happen if the LDAP server is down for example. After the LDAP server is back again secldapclntd will use the negative cache entry and the application initiating the original query will still fail until the cache entry expires. IBM is working on porting the fix to our specific TL and SP levels. What I'm concerned with here, though, is *why* is it timing out? I don't know what the current timeout values are (AIX sucks, etc.) I don't see timeout issues on my Linux boxes, which leads me to believe that either the sssd timouts are longer or that sssd is just more robust when dealing with timeouts. I believe I'm seeing similar behavior with LDAP sudo on AIX as well, because I occasionally have to re-run sudo commands because they initially fail (and I know I'm using the right passwords.) However, sudo doesn't appear to have a cache (or it handles caching better.) Does anyone have any troubleshooting suggestions? Any general speed things up suggestions on the IPA side? Thanks, --Jason -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users Is the server FreeIPA? Can see in the server logs what is actually happening is it the server that really takes time or there is a network connectivity issue or FW is dropping packets? I would really start with the server side logs. As far as 389 goes, run logconv.pl against the access logs in /var/log/dirsrv/slapd-DOMAIN-COM -- 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 listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] slapi-nis bypass Password Policies
On Wed, 2013-09-18 at 12:00 -0500, cbul...@gmail.com wrote: Hi, We have a client server connected to the IPA server using NIS. It's working well but we have a service running at client server that doesn't handle the password expiration properly. Is it possible to bypass the Password Policies from this client server? I am not sure I understand in what way you'd want to bypass them. You'd like to be able to continue to authenticate even if the passwords are expired ? Or you just want to avoid being sent password expiration messages ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
