date:20181220

[Freeipa-users] Re: IPA managed autofs mount timeout

2018-12-20 Thread Jochen Hein via FreeIPA-users

William Muriithi via FreeIPA-users
 writes:

> I am using autofs to mount home directories.  The autofs maps are on IPA
> server. A while back, I adjusted the mount idle timeout from the default 5
> minutes to 2 hours.
>
> I now want to undo the change, essentially bring down the timeout to 5
> minutes.  I can't however remember how I had increased it and google just
> bring up how to adjust locally from /etc/sysconfig/autofs.  I recall
> vaguely I had done the change from IPA.  Anyone who would have this info
> without too much googling?

You can change the timeout globally in /etc/autofs.conf. Otherwise you
can add the --timeout option to the map entries, see auto.master(5) for
details.

So my guess is that you added the timeout to the automountkey. let's see
your automount map/key, something like:

ipa automountkey-show default auto,home --all

Is there a timeout?

Jochen

-- 
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] IPA managed autofs mount timeout

2018-12-20 Thread William Muriithi via FreeIPA-users

Evening,

I have done this before but for the life of me, I can't seem to find a way
to undo my previous change.

I am using autofs to mount home directories.  The autofs maps are on IPA
server. A while back, I adjusted the mount idle timeout from the default 5
minutes to 2 hours.

I now want to undo the change, essentially bring down the timeout to 5
minutes.  I can't however remember how I had increased it and google just
bring up how to adjust locally from /etc/sysconfig/autofs.  I recall
vaguely I had done the change from IPA.  Anyone who would have this info
without too much googling?

Regards,
William
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: dnskeysync stacktrace

2018-12-20 Thread Arjen Heidinga via FreeIPA-users

All,

Apologies for the subject. It translates to 'Encrypted Message'.
Something went wrong with saving to Concepts and other lame excuses.

Arjen

Op 20-12-18 om 21:53 schreef Arjen Heidinga via FreeIPA-users:
> All,
>
> I am here again bothering with my seemingly borked installation. The
> upgrade from 7.0 to 7.2 on fedora 28-29 finished (finaly), when I
> spotted in my journal a stacktrace.
>
> Digging into it, this appears to be the cause. all I find in the
> internet are ancient (solved) bugs...
>
> It appears that it has something to do with DNSSEC. Perhaps this is a
> clue, I do not remember setting this up.
>
> Kind Regards,
>
> Arjen
>
>
> [root@starkey ~]# /usr/libexec/ipa/ipa-dnskeysync-replica
> ipalib.plugable: DEBUG    importing all plugin modules in
> ipaserver.plugins...
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.aci
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.automember
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.automount
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.baseldap
> ipalib.plugable: DEBUG    ipaserver.plugins.baseldap is not a valid
> plugin module
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.baseuser
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.batch
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.ca
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.caacl
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.cert
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.certmap
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.certprofile
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.config
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.delegation
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.dns
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.dnsserver
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.dogtag
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.domainlevel
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.group
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.hbac
> ipalib.plugable: DEBUG    ipaserver.plugins.hbac is not a valid plugin
> module
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.hbacrule
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.hbacsvc
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.hbacsvcgroup
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.hbactest
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.host
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.hostgroup
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.idrange
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.idviews
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.internal
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.join
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.krbtpolicy
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.ldap2
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.location
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.migration
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.misc
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.netgroup
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.otp
> ipalib.plugable: DEBUG    ipaserver.plugins.otp is not a valid plugin module
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.otpconfig
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.otptoken
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.passwd
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.permission
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.ping
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.pkinit
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.privilege
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.pwpolicy
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.rabase
> ipalib.plugable: DEBUG    ipaserver.plugins.rabase is not a valid plugin
> module
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.radiusproxy
> ipalib.plugable: DEBUG    importing plugin module
> ipaserver.plugins.realmdomains
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.role
> ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.schema
> ipalib.plugab

[Freeipa-users] Versleuteld bericht

2018-12-20 Thread Arjen Heidinga via FreeIPA-users

All,

I am here again bothering with my seemingly borked installation. The
upgrade from 7.0 to 7.2 on fedora 28-29 finished (finaly), when I
spotted in my journal a stacktrace.

Digging into it, this appears to be the cause. all I find in the
internet are ancient (solved) bugs...

It appears that it has something to do with DNSSEC. Perhaps this is a
clue, I do not remember setting this up.

Kind Regards,

Arjen


[root@starkey ~]# /usr/libexec/ipa/ipa-dnskeysync-replica
ipalib.plugable: DEBUG    importing all plugin modules in
ipaserver.plugins...
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.aci
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.automember
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.automount
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.baseldap
ipalib.plugable: DEBUG    ipaserver.plugins.baseldap is not a valid
plugin module
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.baseuser
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.batch
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.ca
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.caacl
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.cert
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.certmap
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.certprofile
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.config
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.delegation
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.dns
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.dnsserver
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.dogtag
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.domainlevel
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.group
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.hbac
ipalib.plugable: DEBUG    ipaserver.plugins.hbac is not a valid plugin
module
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.hbacrule
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.hbacsvc
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.hbacsvcgroup
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.hbactest
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.host
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.hostgroup
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.idrange
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.idviews
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.internal
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.join
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.krbtpolicy
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.ldap2
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.location
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.migration
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.misc
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.netgroup
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.otp
ipalib.plugable: DEBUG    ipaserver.plugins.otp is not a valid plugin module
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.otpconfig
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.otptoken
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.passwd
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.permission
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.ping
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.pkinit
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.privilege
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.pwpolicy
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.rabase
ipalib.plugable: DEBUG    ipaserver.plugins.rabase is not a valid plugin
module
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.radiusproxy
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.realmdomains
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.role
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.schema
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.selfservice
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.selinuxusermap
ipalib.plugable: DEBUG    importing plugin module ipaserver.plugins.server
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.serverrole
ipalib.plugable: DEBUG    importing plugin module
ipaserver.plugins.serverroles
ipal

[Freeipa-users] Re: Trouble with pki-tomcat

2018-12-20 Thread Arjen Heidinga via FreeIPA-users

All,

This is solved. For those that find themselves in the same ship as I do,
it was versioning, as Fraser said.

The dir /var/lib/pki/pki-tomcat/ca/webapps was pointing to the wrong pki
package.

# Correct:
[root@starkey webapps]# rpm -qf
/usr/share/pki/ca/webapps/ca/WEB-INF/lib/pki-cmscore.jar
pki-ca-10.6.8-3.fc29.noarch

# Wrong:
[root@starkey webapps]# rpm -qf /usr/share/java/pki/pki-cmscore.jar
pki-server-10.6.8-3.fc29.noarch

In the meantime I am wondering how other's dir's are looking. More
symlinks? This installation is ancient (the 10 yead root-CA expired two
months ago), perhaps something went missing in the fedora updates.


[root@starkey ca]# pwd
/var/lib/pki/pki-tomcat/ca
[root@starkey ca]# ll
total 32
lrwxrwxrwx. 1 pkiuser pkiuser   29 Dec  7  2014 alias ->
/var/lib/pki/pki-tomcat/alias
lrwxrwxrwx. 1 pkiuser pkiuser   22 Dec  7  2014 conf ->
/etc/pki/pki-tomcat/ca
drwxrwx---. 2 pkiuser pkiuser 4096 Dec  7  2014 emails
lrwxrwxrwx. 1 pkiuser pkiuser   26 Dec  7  2014 logs ->
/var/log/pki/pki-tomcat/ca
drwxrwx---. 3 pkiuser pkiuser 4096 Dec  7  2014 profiles
lrwxrwxrwx. 1 pkiuser pkiuser   36 Dec  7  2014 registry ->
/etc/sysconfig/pki/tomcat/pki-tomcat
lrwxrwxrwx. 1 root    root  25 Dec 20 14:12 webapps ->
/usr/share/pki/ca/webapps

Kind Regards,

Arjen Heidinga


Op 14-12-18 om 15:52 schreef Arjen Heidinga via FreeIPA-users:
> Dear all,
>
> I fear somehow my freeipa server is broken. Perhaps it is time to create
> a new one, however that would be very time-consuming.
>
> Yesterday everything broke, after FreeIPA was upgraded. It is worth
> mentioning that I had certificate issues recently. My root-CA, and
> httpd-cert expired.
>
> When I start the tomcat-pki daemon, I get presented the stacktrace
> below. Note to mention, the pcscd lines are everytime exactly there when
> trying to start.
>
> I'd appreciate it if someone has a clue.
>
> Kind Regards,
>
> Arjen Heidinga
>
>
> Dec 14 15:31:44 starkey.platypusnet.org systemd[1]: Starting PKI Tomcat
> Server pki-tomcat...
> -- Subject: Unit pki-tomcatd@pki-tomcat.service has begun start-up
> -- Defined-By: systemd
> -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


signature.asc
Description: OpenPGP digital signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Web UI login/certificate issues, IPA 4.5.4

2018-12-20 Thread dbischof--- via FreeIPA-users


Hi Florence,

On Thu, 20 Dec 2018, Florence Blanc-Renaud via FreeIPA-users wrote:


On 12/20/18 4:22 PM, dbischof--- via FreeIPA-users wrote:

 my IPA system consists of 2 masters with their own self-signed CAs, one of
 them being the certificate renewal master (ipa1). The system has been
 running for years and has been migrated from an IPA 3 system.

 Since a while, the Web UI logins on ipa1 don't work anymore ("Login failed
 due to an unknown reason.").

 Web UI logins on the other server (ipa2) work and everything else is
 working fine, too, ipactl status reports all services running.

 On login attempt:

 --- httpd log
 [...]
 [:error] [pid 15551] [remote 141.51.X.X:0] mod_wsgi (pid=15551): Exception
 occurred processing WSGI script '/usr/share/ipa/wsgi.py'.
 [...]
 [:error] [pid 15551] [remote 141.51.X.X:0] CalledProcessError: Command
 '/usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_15551 -X
 X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X
 X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem' returned
 non-zero exit status 1
 ---

 --- krb5kdc.log
 [...]
 Dec 20 16:06:54 ipa1.example.com krb5kdc[15517](info): AS_REQ (8 etypes
 {18 17 20 19 16 23 25 26}) 141.51.X.Y: NEEDED_PREAUTH:
 WELLKNOWN/anonym...@example.com for krbtgt/example@example.com,
 Additional pre-authentication required
 Dec 20 16:06:54 ipa1.example.com krb5kdc[15517](info): closing down fd 11
 Dec 20 16:06:54 ipa1.example.com krb5kdc[15518](info): AS_REQ (8 etypes
 {18 17 20 19 16 23 25 26}) 141.51.X.Y: KDC_RETURN_PADATA:
 WELLKNOWN/anonym...@example.com for krbtgt/example@example.com, Failed
 to verify own certificate (depth 0): certificate has expired
 Dec 20 16:06:54 ipa1.example.com krb5kdc[15518](info): closing down fd 11
 ---

 --- ipa-checkcerts.py
 IPA version 4.5.4-10.el7.centos.3
 Check CA status
 Check tracking
 Check NSS trust
 Check dates
 Checking certificates in CS.cfg
 Comparing certificates to requests in LDAP
 Checking RA certificate
 Checking authorities
 Checking host keytab
 Validating certificates
 Checking renewal master
 End-to-end cert API test
 Checking permissions and ownership
 Failures:
 Unable to find request for serial 268304391
 Unable to find request for serial 268304394
 Unable to find request for serial 268304393
 Unable to find request for serial 268304392
 Subject O=EXAMPLE.COM,CN=ipa2.example.com and template subject
 CN=ipa1.example.com,O=EXAMPLE.COM do not match for serial 57
 ---

 --- ipa pkinit-status --all
 -
 2 servers matched
 -
    Server name: ipa2.example.com
    PKINIT status: enabled

    Server name: ipa1.example.com
    PKINIT status: enabled
 
 Number of entries returned 2
 

 To my understanding, proper certificate exchange between my two servers
 ceased working at some point. How do i track this down and fix it?

your issue looks similar to ticket #6792 [1]. Can you check the result of 
upgrade in /var/log/ipaupgrade.log?

Also check the output of
$ ipa-pkinit-manage status
and if the files /var/lib/ipa-client/pki/kdc-ca-bundle.pem and 
/var/lib/ipa-client/pki/ca-bundle.pem exist, with -rw-r--r-- permissions.


Regarding the certificates, does getcert list show expired certs?
flo

[1] https://pagure.io/freeipa/issue/6792


---
$ ipa-pkinit-manage status
PKINIT is enabled
---

There are no expired certificates, kdc-ca-bundle.pem and ca-bundle.pem 
exist with proper permissions, but I found something in ipaupgrade.log:


---
2018-09-12T13:37:18Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -L -f 
/etc/httpd/alias/pwdfile.txt
2018-09-12T13:37:19Z DEBUG Process finished, return code=0
2018-09-12T13:37:19Z DEBUG stdout=
Certificate Nickname Trust 
Attributes


SSL,S/MIME,JAR/XPI

Server-Cert  u,u,u
EXAMPLE.COM IPA CA   CT,C,C

2018-09-12T13:37:19Z DEBUG stderr=
2018-09-12T13:37:19Z DEBUG Starting external process
2018-09-12T13:37:19Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -L -n 
EXAMPLE.COM IPA CA -a -f /etc/httpd/alias/pwdfile.txt
2018-09-12T13:37:19Z DEBUG Process finished, return code=0
2018-09-12T13:37:19Z DEBUG stdout=
-BEGIN CERTIFICATE-
[...]
-END CERTIFICATE-

2018-09-12T13:37:19Z DEBUG stderr=
2018-09-12T13:37:19Z DEBUG Executing upgrade plugin: update_ra_cert_store
2018-09-12T13:37:19Z DEBUG raw: update_ra_cert_store
2018-09-12T13:37:19Z DEBUG raw: ca_is_enabled(version=u'2.228')
2018-09-12T13:37:19Z DEBUG ca_is_enabled(version=u'2.228')
2018-09-12T13:37:19Z DEBUG Starting external process
2018-09-12T13:37:19Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -L -n 
ipaCert -a -f /etc/httpd/alias/pwdfile.txt
2018-09-12T13:37:19Z DEBUG Process finished, return code=255
2018-09-12T13:37:19Z DEBUG stdout=
2018-09-12T13:37:19Z DEBUG stderr=certutil: Could not find cert: ipaCert
: PR_FILE_NOT_FOUND_ERROR: File not found

[Freeipa-users] Re: FreeIPA/Dogtag - Slow host deletion due to certificate pagination

2018-12-20 Thread Jared Ledvina via FreeIPA-users

Hi Florence,

Thanks for the reply! So, I've been looking at those and I currently, don't 
have any limit that I can find configured to 2,000 entries. 

Current setup: https://paste.fedoraproject.org/paste/75jhSM1qonlQB-Uqtgug-Q

However, with those set, and after restarting ipa (to make sure any setting 
that requires a restart is in-place), we still see this:
# ipa cert-find --hosts=testhost-abc-notreal-1.ops.example.com
--
0 certificates matched
--

Number of entries returned 0


# /var/log/pki/pki-tomcat/ca/debug
[20/Dec/2018:17:19:59][ajp-bio-127.0.0.1-8009-exec-3]: 
DBVirtualList.getEntries()
[20/Dec/2018:17:20:00][ajp-bio-127.0.0.1-8009-exec-3]: getEntries: exception 
java.lang.ClassCastException: netscape.ldap.LDAPException cannot be cast to 
netscape.ldap.LDAPEntry
[20/Dec/2018:17:20:00][ajp-bio-127.0.0.1-8009-exec-3]: DBVirtualList: entries: 
2000
[20/Dec/2018:17:20:00][ajp-bio-127.0.0.1-8009-exec-3]: 
DBVirtualList.getPage(5998)
[20/Dec/2018:17:20:00][ajp-bio-127.0.0.1-8009-exec-3]: 
DBVirtualList.getEntries()
[20/Dec/2018:17:20:00][ajp-bio-127.0.0.1-8009-exec-3]: getEntries: exception 
java.lang.ClassCastException: netscape.ldap.LDAPException cannot be cast to 
netscape.ldap.LDAPEntry
[20/Dec/2018:17:20:00][ajp-bio-127.0.0.1-8009-exec-3]: DBVirtualList: entries: 
2000
[20/Dec/2018:17:20:00][ajp-bio-127.0.0.1-8009-exec-3]: 
DBVirtualList.getPage(7997)
[20/Dec/2018:17:20:00][ajp-bio-127.0.0.1-8009-exec-3]: 
DBVirtualList.getEntries()
[20/Dec/2018:17:20:00][ajp-bio-127.0.0.1-8009-exec-3]: DBVirtualList: entries: 
1842


Any other ideas on what is causing these entries to be paginated at 2,000 
entries? 

As I mentioned on https://bugzilla.redhat.com/show_bug.cgi?id=1658280 as well, 
sizeLimit and timeLimit in the LDAP request being sent to 389-ds as 0/unset 
(it's not clear if wireshark is changing that to 0). 

Thanks,
Jared
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Web UI login/certificate issues, IPA 4.5.4

2018-12-20 Thread Florence Blanc-Renaud via FreeIPA-users


On 12/20/18 4:22 PM, dbischof--- via FreeIPA-users wrote:

Hi,

my IPA system consists of 2 masters with their own self-signed CAs, one 
of them being the certificate renewal master (ipa1). The system has been 
running for years and has been migrated from an IPA 3 system.


Since a while, the Web UI logins on ipa1 don't work anymore ("Login 
failed due to an unknown reason.").


Web UI logins on the other server (ipa2) work and everything else is 
working fine, too, ipactl status reports all services running.


On login attempt:

--- httpd log
[...]
[:error] [pid 15551] [remote 141.51.X.X:0] mod_wsgi (pid=15551): 
Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'.

[...]
[:error] [pid 15551] [remote 141.51.X.X:0] CalledProcessError: Command 
'/usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_15551 -X 
X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X 
X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem' returned 
non-zero exit status 1

---

--- krb5kdc.log
[...]
Dec 20 16:06:54 ipa1.example.com krb5kdc[15517](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 141.51.X.Y: NEEDED_PREAUTH: 
WELLKNOWN/anonym...@example.com for krbtgt/example@example.com, 
Additional pre-authentication required

Dec 20 16:06:54 ipa1.example.com krb5kdc[15517](info): closing down fd 11
Dec 20 16:06:54 ipa1.example.com krb5kdc[15518](info): AS_REQ (8 etypes 
{18 17 20 19 16 23 25 26}) 141.51.X.Y: KDC_RETURN_PADATA: 
WELLKNOWN/anonym...@example.com for krbtgt/example@example.com, 
Failed to verify own certificate (depth 0): certificate has expired

Dec 20 16:06:54 ipa1.example.com krb5kdc[15518](info): closing down fd 11
---

--- ipa-checkcerts.py
IPA version 4.5.4-10.el7.centos.3
Check CA status
Check tracking
Check NSS trust
Check dates
Checking certificates in CS.cfg
Comparing certificates to requests in LDAP
Checking RA certificate
Checking authorities
Checking host keytab
Validating certificates
Checking renewal master
End-to-end cert API test
Checking permissions and ownership
Failures:
Unable to find request for serial 268304391
Unable to find request for serial 268304394
Unable to find request for serial 268304393
Unable to find request for serial 268304392
Subject O=EXAMPLE.COM,CN=ipa2.example.com and template subject 
CN=ipa1.example.com,O=EXAMPLE.COM do not match for serial 57

---

--- ipa pkinit-status --all
-
2 servers matched
-
   Server name: ipa2.example.com
   PKINIT status: enabled

   Server name: ipa1.example.com
   PKINIT status: enabled

Number of entries returned 2


To my understanding, proper certificate exchange between my two servers 
ceased working at some point. How do i track this down and fix it?



Hi,

your issue looks similar to ticket #6792 [1]. Can you check the result 
of upgrade in /var/log/ipaupgrade.log?

Also check the output of
$ ipa-pkinit-manage status
and if the files /var/lib/ipa-client/pki/kdc-ca-bundle.pem and 
/var/lib/ipa-client/pki/ca-bundle.pem exist, with -rw-r--r-- permissions.


Regarding the certificates, does getcert list show expired certs?
flo

[1] https://pagure.io/freeipa/issue/6792


Mit freundlichen Gruessen/With best regards,

--Daniel.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org 


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Moving IPA master to a new server fails to start krb5kdc

2018-12-20 Thread Florence Blanc-Renaud via FreeIPA-users

On 12/20/18 11:51 AM, Kees Bakker via FreeIPA-users wrote:

On 19-12-18 12:06, Kees Bakker via FreeIPA-users wrote:

On 18-12-18 17:50, Florence Blanc-Renaud wrote:
[...]

If you have a spare machine you can also use replication, and create a replica
of your current master with all the needed services (CA, KRA, DNS if needed).
If you really need to keep the same hostname, then you will need a spare
machine:
1. create serverB as a replica of serverA on your spare machine. Do not forget
to promote serverB as CA renewal master and CRL master [2].
2. decommission serverA with (on serverA) ipa-server-install --uninstall and
(on serverB) ipa-replica-manage del serverA --clean
3. provision your new hardware with hostname=serverA, install serverA as a
replica of serverB.
I would advise to keep serverB as it will provide redundancy.

This wiki [3] also explains the preferred paths depending on your situation.

I have read that document too. First I want to give it another try. If it
fails again I will follow advice described above.

Thanks for your help.

HTH,
flo

[1]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/#backup-restore
[2] https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master
[3] https://www.freeipa.org/page/Backup_and_Restore

Just to let you know, I have given up with my "rsync" procedure. I am now
following the steps above. Well, except step3, because I didn't want to add
even more hardware in the process (the "spare machine" mentioned above).

Step 1 is completed. Promotion of CA renewal and CRL master is done.

I have a remaining question.
What do I do with all the IPA clients that point to serverA? At some point I
want to execute step 2, and shut off that system. I briefly looked at the files
in /etc and found these (alblas is my serverA):

If your applications are using DNS to find the server, they will be
fine. But some have hardcoded values and need to be reconfigured.

/etc/sssd/sssd.conf:ipa_server = _srv_, alblas.ghs.nl
Please have a look at the man page sssd-ipa(5), especially the SERVICE
DISCOVERY section. _srv_ means that service discovery will be used to
find a server, and if no servers can be discovered using DNS, alblas
will be used instead.

/etc/ipa/default.conf:server = alblas.ghs.nl
/etc/ipa/default.conf:xmlrpc_uri = https://alblas.ghs.nl/ipa/xml
default.conf is used for all the ipa * commands. By defaut, the command
will start with the configured xmlrpc_uri but if it fails, it will fall
back to the _ldap._tcp. servers found in the DNS.
So if you replace alblas with the new servre hostname you will speed up
the command.

/etc/ntp.conf:server alblas.ghs.nl
/etc/ldap/ldap.conf:URI ldaps://alblas.ghs.nl

The URI is used as default if none is provided to ldapsearch.

Do I have to visit each client and modify these files? Anything else?

Before completely removing your initial server, perform ipactl stop on
the initial server and check that the clients are still working:

# id $USER
# kinit $USER
# ipa user-find
# host `hostname`
# ipa cert-find 1

HTH,
flo
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Single Sign On (SSO) SSH via IP Address

2018-12-20 Thread Theese, David C via FreeIPA-users

Bryan,

Thanks a ton! I am working on this now.

Informationally, I'll pass along that after reading your email last night where 
you mentioned the client looking for a host/10.10.1...@example.com principal, I 
found that logging onto the host and using ipa-join -h  created 
such an IP address-based host principal on the KDC. So, the -h option will take 
an IP address as well as a hostname (my guess is that it interprets whatever 
you give it as just a string and that it doesn't really matter what you call 
it). This then allowed me to SSH to the host via IP address in a passwordless 
manner (i.e. via my Kerberos ticket)!

However, setting up an IP address-based host principal for every interface in 
our network is very burdensome. Getting SSH SSO working via proper 
configuration of Kerberos or SSH, as you suggest, is definitely preferable.

So I made these changes:

* I removed the IP address-based principal from FreeIPA (i.e. from Kerberos)
* dna_canonicalize_hostname is set to true by default. Nonetheless, I 
explicitly set it to true in /etc/krb5.conf on the host I'm trying to log into 
via passwordless SSH.
* Kerberos configuration parameter "rdns" also seems quite relevant. It 
defaults to true, though we'd been explicitly setting it to false. So, I 
explicitly set it to true.
* I rebooted the host
* I restarted the KDC

Having done all of this, I found that I could not perform passwordless ssh to 
the host in question by IP address. I was prompted for a password.

BTW, while I'm at this point, do you by chance know what particular services, 
if any, must be restarted after modifying  /etc/krb5.conf? It's a pain to 
reboot for every experiment just because I'm not sure if anything needs to be 
restarted...

I also found that the following did not do the trick:
ssh -o "GSSAPITrustDns=yes" 10.10.10.5

As far as the confirmation of the reverse pointer you'd requested, below is an 
actual cut-and-paste from my command terminal, but I have necessarily sanitized 
the output. So, even though it has things like "example.com" in it, it is an 
actual, real run of dig to verify proper forward / reverse DNS resolution:

my-u...@host-1.example.com$ dig +short -x 10.10.10.5
host-2.example.com.
my-u...@host-1.example.com$ dig +short host-2.example.com
10.10.10.5

As to my SSH client configuration... My version of SSH (OpenSSH_6.6.1p1) does 
not have the -G option. Do you by chance know how I can print out, at run time, 
the configuration actually used?

So, still working on trying to find the right configuration to allow 
passwordless SSH via IP address to work...

Thanks so much!

Dave

-Original Message-
From: Bryan Mesich [mailto:bryan.mes...@digikey.com] 
Sent: Thursday, December 20, 2018 8:02 AM
To: FreeIPA users list
Cc: Theese, David C
Subject: Re: [Freeipa-users] Re: Single Sign On (SSO) SSH via IP Address

On Wed, Dec 19, 2018 at 09:41:49PM -0600, Bryan Mesich via FreeIPA-users wrote:
> On Wed, Dec 19, 2018 at 09:18:35PM -0600, Bryan Mesich via FreeIPA-users 
> wrote:

[snip...]

> I was able to reproduce the problem on my end.  I forgot that Kerberos
> can canonicalize host names.  If I set "dns_canonicalize_hostname =
> false" under the [libdefaults] section (in krb5.conf on client), I get
> the same problem:
> 
> debug1: Unspecified GSS failure.  Minor code may provide more
> information Server host/10.10.128...@xx..com not found in Kerberos 
> database
> 
> Try setting it to true and see what happens.

GSSAPITrustDns=yes in ssh_conf should also do the trick.  You can decide
where you want the canonicalization to occur, ssh or krb5.

Bryan

> 
> Bryan
-- 
Bryan Mesich
Sr. System Administrator
DIGI-KEY ELECTRONICS
701 Brooks Ave. South
Thief River Falls, MN 56701 USA
bryan.mes...@digikey.com
218.681.8000 x6104

Powered by Linux 3.10.0-862.6.3.el7.x86_64
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Vault feature for AD users

2018-12-20 Thread Alexander Bokovoy via FreeIPA-users


On to, 20 joulu 2018, Ronald Wimmer via FreeIPA-users wrote:

Is it true that this feature is only available to native ipa users?

'ipa help vault' has this description:



Based on the ownership there are three vault categories:
* user/private vault
* service vault
* shared vault

User vaults are vaults owned used by a particular user. Private
vaults are vaults owned the current user. Service vaults are
vaults owned by a service. Shared vaults are owned by the admin
but they can be used by other users or services.



As AD users aren't stored in LDAP, they cannot be made owners.

Could you please file a request asking for this support? I have been
working on ability to manage FreeIPA as an AD user (see
https://github.com/abbra/freeipa-adusers-admins) but it doesn't work
magically on all objects and needs a support for multiple sides. In case
of vaults, there are implicit internal assumptions that if it is not a
service or a shared vault, it is an IPA user.



On 30.11.18 09:42, Ronald Wimmer via FreeIPA-users wrote:
Is there any possibility to use the vault feature for external (AD) 
users?

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org

Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Limits exceeded for this query

2018-12-20 Thread lune voo via FreeIPA-users

Thanks for all these answers guys (and woman) o/

Lune

Le jeu. 20 déc. 2018 à 16:23, Mark Reynolds  a écrit :

>
> On 12/20/18 10:13 AM, lune voo via FreeIPA-users wrote:
>
> Re Florence.
>
> I performed the following command :
>
> ipa config-mod --searchtimelimit=5
>
>
> It solved this "problem".
>
> May I ask what can be the impacts on increasing searchtimelimit please ?
>
> Hi Lune,
>
> The purpose of setting these kinds of limits is to prevent clients from
> abusing the Directory Server/IDM and causing potential DOS attacks.  If you
> increase the search time limit it just means that any client can run
> "longer" searches and tie up Directory Server/IDM resources longer.  That
> being said, 5 seconds or 10 seconds are very reasonable limits, but for
> example setting it to an hour would not be.
>
> HTH,
>
> Mark
>
>
> Best regards.
>
>
> Lune
>
>
>
>
> Le jeu. 20 déc. 2018 à 12:37, Florence Blanc-Renaud  a
> écrit :
>
>> Hi,
>>
>> based on the err code err=3 I can see that I was wrong, it's not a size
>> limit but rather a time limit issue. It looks like the LDAP server is
>> busy after the modification on the cn= entry and takes more
>> than 33sec to answer.
>>
>> The default search time limit is 2 seconds at IPA level:
>> dn: cn=ipaConfig,cn=etc,$BASEDN
>> ipaSearchTimeLimit: 2
>>
>> There is also a search time limit set at 389-ds level:
>> dn: cn=config
>> nsslapd-timelimit: 3600
>>
>> and another one can be set per-user:
>> dn: uid=,cn=users,cn=accounts,$BASEDN
>> nsTimeLimit: 
>>
>> Is there anything in the error log of 389-ds at the same time?
>>
>> Note that IPA 3.0.0 is quite old and we did improvements related to
>> group management in more recent versions (for instance [1] or [2]).
>> The failing search may simply be an internal search in order to get the
>> size and time limits, needed to create the search that will check the
>> content of the entry after the MOD has been done.
>>
>> flo
>>
>> [1] https://pagure.io/freeipa/issue/4965
>> [2] https://pagure.io/freeipa/issue/4947
>>
>> On 12/20/18 11:38 AM, lune voo via FreeIPA-users wrote:
>> > I tried to perform an ldapsearch using the same kind of command :
>> >
>> > ldapsearch -x -D "cn=Directory Manager" \
>> >>   -h  \
>> >>   -p 389 \
>> >>   -W \
>> >>   -b "cn=ipaconfig,cn=etc,dc=" \
>> >>   -s sub \
>> >> objectclass=*
>> > Enter LDAP Password:
>> >
>> >
>> > I got this result immediately :
>> > # extended LDIF
>> > #
>> > # LDAPv3
>> > # base > with scope subtree
>> > # filter: objectclass=*
>> > # requesting: ALL
>> > #
>> >
>> > # ipaConfig, etc, 
>> > dn: cn=ipaConfig,cn=etc,dc=
>> > objectClass: nsContainer
>> > objectClass: top
>> > objectClass: ipaGuiConfig
>> > objectClass: ipaConfigObject
>> > ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
>> > ipaGroupSearchFields: cn,description
>> > ipaSearchTimeLimit: 2
>> > ipaSearchRecordsLimit: 100
>> > ipaHomesRootDir: /home
>> > ipaDefaultLoginShell: /bin/sh
>> > ipaDefaultPrimaryGroup: users
>> > ipaMaxUsernameLength: 64
>> > ipaPwdExpAdvNotify: 4
>> > ipaGroupObjectClasses: top
>> > ipaGroupObjectClasses: groupofnames
>> > ipaGroupObjectClasses: nestedgroup
>> > ipaGroupObjectClasses: ipausergroup
>> > ipaGroupObjectClasses: ipaobject
>> > ipaUserObjectClasses: top
>> > ipaUserObjectClasses: person
>> > ipaUserObjectClasses: organizationalperson
>> > ipaUserObjectClasses: inetorgperson
>> > ipaUserObjectClasses: inetuser
>> > ipaUserObjectClasses: posixaccount
>> > ipaUserObjectClasses: krbprincipalaux
>> > ipaUserObjectClasses: krbticketpolicyaux
>> > ipaUserObjectClasses: ipaobject
>> > ipaUserObjectClasses: ipasshuser
>> > ipaDefaultEmailDomain: 
>> > ipaMigrationEnabled: FALSE
>> > ipaConfigString: AllowNThash
>> > ipaSELinuxUserMapOrder:
>> > guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c102
>> >   3$unconfined_u:s0-s0:c0.c1023
>> > ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023
>> > cn: ipaConfig
>> > ipaCertificateSubjectBase: O=
>> > ipaKrbAuthzData: MS-PAC
>> >
>> > # search result
>> > search: 2
>> > result: 0 Success
>> >
>> > # numResponses: 2
>> > # numEntries: 1
>> >
>> > This query is fine and fast.
>> >
>> > Best regards.
>> >
>> > Lune
>> >
>> >
>> > Le jeu. 20 déc. 2018 à 11:25, lune voo > > > a écrit :
>> >
>> > Here is the value of nsslapd-sizelimit
>> >
>> > nsslapd-sizelimit: 2000
>> >
>> > For the anonymous queries, we disabled them long time ago.
>> >
>> > If I understand well, the problem comes from this search :
>> > SRCH base="cn=ipaconfig,cn=etc,dc=" scope=0
>> > filter="(objectClass=*)" attrs=ALL
>> >
>> > Do you know why this search is performed once the member user has
>> > been removed from the group ?
>> >
>> > Lune
>> >
>> > Le jeu. 20 déc. 2018 à 11:08, lune voo > > > a écrit :
>> >
>> > Hello Florence.
>> >
>> > Can you see in 389-ds logs which operation is triggering the
>> > size-

[Freeipa-users] Re: Limits exceeded for this query

2018-12-20 Thread Mark Reynolds via FreeIPA-users



On 12/20/18 10:13 AM, lune voo via FreeIPA-users wrote:

Re Florence.

I performed the following command :

ipa config-mod --searchtimelimit=5


It solved this "problem".

May I ask what can be the impacts on increasing searchtimelimit please ?


Hi Lune,

The purpose of setting these kinds of limits is to prevent clients from 
abusing the Directory Server/IDM and causing potential DOS attacks.  If 
you increase the search time limit it just means that any client can run 
"longer" searches and tie up Directory Server/IDM resources longer.  
That being said, 5 seconds or 10 seconds are very reasonable limits, but 
for example setting it to an hour would not be.


HTH,

Mark



Best regards.


Lune




Le jeu. 20 déc. 2018 à 12:37, Florence Blanc-Renaud > a écrit :


Hi,

based on the err code err=3 I can see that I was wrong, it's not a
size
limit but rather a time limit issue. It looks like the LDAP server is
busy after the modification on the cn= entry and takes
more
than 33sec to answer.

The default search time limit is 2 seconds at IPA level:
dn: cn=ipaConfig,cn=etc,$BASEDN
ipaSearchTimeLimit: 2

There is also a search time limit set at 389-ds level:
dn: cn=config
nsslapd-timelimit: 3600

and another one can be set per-user:
dn: uid=,cn=users,cn=accounts,$BASEDN
nsTimeLimit: 

Is there anything in the error log of 389-ds at the same time?

Note that IPA 3.0.0 is quite old and we did improvements related to
group management in more recent versions (for instance [1] or [2]).
The failing search may simply be an internal search in order to
get the
size and time limits, needed to create the search that will check the
content of the entry after the MOD has been done.

flo

[1] https://pagure.io/freeipa/issue/4965
[2] https://pagure.io/freeipa/issue/4947

On 12/20/18 11:38 AM, lune voo via FreeIPA-users wrote:
> I tried to perform an ldapsearch using the same kind of command :
>
> ldapsearch -x -D "cn=Directory Manager" \
>>   -h  \
>>   -p 389 \
>>   -W \
>>   -b "cn=ipaconfig,cn=etc,dc=" \
>>   -s sub \
>> objectclass=*
> Enter LDAP Password:
>
>
> I got this result immediately :
> # extended LDIF
> #
> # LDAPv3
> # base > with scope subtree
> # filter: objectclass=*
> # requesting: ALL
> #
>
> # ipaConfig, etc, 
> dn: cn=ipaConfig,cn=etc,dc=
> objectClass: nsContainer
> objectClass: top
> objectClass: ipaGuiConfig
> objectClass: ipaConfigObject
> ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
> ipaGroupSearchFields: cn,description
> ipaSearchTimeLimit: 2
> ipaSearchRecordsLimit: 100
> ipaHomesRootDir: /home
> ipaDefaultLoginShell: /bin/sh
> ipaDefaultPrimaryGroup: users
> ipaMaxUsernameLength: 64
> ipaPwdExpAdvNotify: 4
> ipaGroupObjectClasses: top
> ipaGroupObjectClasses: groupofnames
> ipaGroupObjectClasses: nestedgroup
> ipaGroupObjectClasses: ipausergroup
> ipaGroupObjectClasses: ipaobject
> ipaUserObjectClasses: top
> ipaUserObjectClasses: person
> ipaUserObjectClasses: organizationalperson
> ipaUserObjectClasses: inetorgperson
> ipaUserObjectClasses: inetuser
> ipaUserObjectClasses: posixaccount
> ipaUserObjectClasses: krbprincipalaux
> ipaUserObjectClasses: krbticketpolicyaux
> ipaUserObjectClasses: ipaobject
> ipaUserObjectClasses: ipasshuser
> ipaDefaultEmailDomain: 
> ipaMigrationEnabled: FALSE
> ipaConfigString: AllowNThash
> ipaSELinuxUserMapOrder:
> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c102
>   3$unconfined_u:s0-s0:c0.c1023
> ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023
> cn: ipaConfig
> ipaCertificateSubjectBase: O=
> ipaKrbAuthzData: MS-PAC
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> This query is fine and fast.
>
> Best regards.
>
> Lune
>
>
> Le jeu. 20 déc. 2018 à 11:25, lune voo mailto:lune.voo1...@gmail.com>
> >>
a écrit :
>
>     Here is the value of nsslapd-sizelimit
>
>     nsslapd-sizelimit: 2000
>
>     For the anonymous queries, we disabled them long time ago.
>
>     If I understand well, the problem comes from this search :
>     SRCH base="cn=ipaconfig,cn=etc,dc=" scope=0
>     filter="(objectClass=*)" attrs=ALL
>
>     Do you know why this search is performed once the member
user has
>     been removed from the group ?
>
>     Lune
>
>     Le jeu. 20 déc. 2018 à 11:08, lune voo
mailto:lune.voo1...@gmail.com>
>     >> a écrit :
>
>

[Freeipa-users] Re: Limits exceeded for this query

2018-12-20 Thread François Cami via FreeIPA-users

Hi Lune,

On Thu, Dec 20, 2018 at 4:14 PM lune voo via FreeIPA-users
 wrote:
>
> Re Florence.
>
> I performed the following command :
>
> ipa config-mod --searchtimelimit=5
>
>
> It solved this "problem".
>
> May I ask what can be the impacts on increasing searchtimelimit please ?

It's a safeguard to make sure the server cannot be kept busy for long
periods of time by long-running requests.

5 seconds is OK, but if you want to be on the safe side of things you
can revert to the default value until you need to run "ipa
group-remove-member" again.

As Florence mentioned improvements have been made in that area in
newer versions of FreeIPA.

Best regards,
François

>
> Best regards.
>
>
> Lune
>
>
>
>
> Le jeu. 20 déc. 2018 à 12:37, Florence Blanc-Renaud  a écrit 
> :
>>
>> Hi,
>>
>> based on the err code err=3 I can see that I was wrong, it's not a size
>> limit but rather a time limit issue. It looks like the LDAP server is
>> busy after the modification on the cn= entry and takes more
>> than 33sec to answer.
>>
>> The default search time limit is 2 seconds at IPA level:
>> dn: cn=ipaConfig,cn=etc,$BASEDN
>> ipaSearchTimeLimit: 2
>>
>> There is also a search time limit set at 389-ds level:
>> dn: cn=config
>> nsslapd-timelimit: 3600
>>
>> and another one can be set per-user:
>> dn: uid=,cn=users,cn=accounts,$BASEDN
>> nsTimeLimit: 
>>
>> Is there anything in the error log of 389-ds at the same time?
>>
>> Note that IPA 3.0.0 is quite old and we did improvements related to
>> group management in more recent versions (for instance [1] or [2]).
>> The failing search may simply be an internal search in order to get the
>> size and time limits, needed to create the search that will check the
>> content of the entry after the MOD has been done.
>>
>> flo
>>
>> [1] https://pagure.io/freeipa/issue/4965
>> [2] https://pagure.io/freeipa/issue/4947
>>
>> On 12/20/18 11:38 AM, lune voo via FreeIPA-users wrote:
>> > I tried to perform an ldapsearch using the same kind of command :
>> >
>> > ldapsearch -x -D "cn=Directory Manager" \
>> >>   -h  \
>> >>   -p 389 \
>> >>   -W \
>> >>   -b "cn=ipaconfig,cn=etc,dc=" \
>> >>   -s sub \
>> >> objectclass=*
>> > Enter LDAP Password:
>> >
>> >
>> > I got this result immediately :
>> > # extended LDIF
>> > #
>> > # LDAPv3
>> > # base > with scope subtree
>> > # filter: objectclass=*
>> > # requesting: ALL
>> > #
>> >
>> > # ipaConfig, etc, 
>> > dn: cn=ipaConfig,cn=etc,dc=
>> > objectClass: nsContainer
>> > objectClass: top
>> > objectClass: ipaGuiConfig
>> > objectClass: ipaConfigObject
>> > ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
>> > ipaGroupSearchFields: cn,description
>> > ipaSearchTimeLimit: 2
>> > ipaSearchRecordsLimit: 100
>> > ipaHomesRootDir: /home
>> > ipaDefaultLoginShell: /bin/sh
>> > ipaDefaultPrimaryGroup: users
>> > ipaMaxUsernameLength: 64
>> > ipaPwdExpAdvNotify: 4
>> > ipaGroupObjectClasses: top
>> > ipaGroupObjectClasses: groupofnames
>> > ipaGroupObjectClasses: nestedgroup
>> > ipaGroupObjectClasses: ipausergroup
>> > ipaGroupObjectClasses: ipaobject
>> > ipaUserObjectClasses: top
>> > ipaUserObjectClasses: person
>> > ipaUserObjectClasses: organizationalperson
>> > ipaUserObjectClasses: inetorgperson
>> > ipaUserObjectClasses: inetuser
>> > ipaUserObjectClasses: posixaccount
>> > ipaUserObjectClasses: krbprincipalaux
>> > ipaUserObjectClasses: krbticketpolicyaux
>> > ipaUserObjectClasses: ipaobject
>> > ipaUserObjectClasses: ipasshuser
>> > ipaDefaultEmailDomain: 
>> > ipaMigrationEnabled: FALSE
>> > ipaConfigString: AllowNThash
>> > ipaSELinuxUserMapOrder:
>> > guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c102
>> >   3$unconfined_u:s0-s0:c0.c1023
>> > ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023
>> > cn: ipaConfig
>> > ipaCertificateSubjectBase: O=
>> > ipaKrbAuthzData: MS-PAC
>> >
>> > # search result
>> > search: 2
>> > result: 0 Success
>> >
>> > # numResponses: 2
>> > # numEntries: 1
>> >
>> > This query is fine and fast.
>> >
>> > Best regards.
>> >
>> > Lune
>> >
>> >
>> > Le jeu. 20 déc. 2018 à 11:25, lune voo > > > a écrit :
>> >
>> > Here is the value of nsslapd-sizelimit
>> >
>> > nsslapd-sizelimit: 2000
>> >
>> > For the anonymous queries, we disabled them long time ago.
>> >
>> > If I understand well, the problem comes from this search :
>> > SRCH base="cn=ipaconfig,cn=etc,dc=" scope=0
>> > filter="(objectClass=*)" attrs=ALL
>> >
>> > Do you know why this search is performed once the member user has
>> > been removed from the group ?
>> >
>> > Lune
>> >
>> > Le jeu. 20 déc. 2018 à 11:08, lune voo > > > a écrit :
>> >
>> > Hello Florence.
>> >
>> > Can you see in 389-ds logs which operation is triggering the
>> > size-limit
>> > error? In /var/log/dirsrv/slapd-domXXX/access, you will find
>> > a line with
>> > RESULT err=4, note the conn

[Freeipa-users] Web UI login/certificate issues, IPA 4.5.4

2018-12-20 Thread dbischof--- via FreeIPA-users


Hi,

my IPA system consists of 2 masters with their own self-signed CAs, one of 
them being the certificate renewal master (ipa1). The system has been 
running for years and has been migrated from an IPA 3 system.


Since a while, the Web UI logins on ipa1 don't work anymore ("Login failed 
due to an unknown reason.").


Web UI logins on the other server (ipa2) work and everything else is 
working fine, too, ipactl status reports all services running.


On login attempt:

--- httpd log
[...]
[:error] [pid 15551] [remote 141.51.X.X:0] mod_wsgi (pid=15551): Exception 
occurred processing WSGI script '/usr/share/ipa/wsgi.py'.
[...]
[:error] [pid 15551] [remote 141.51.X.X:0] CalledProcessError: Command 
'/usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_15551 -X 
X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X 
X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem' returned non-zero 
exit status 1
---

--- krb5kdc.log
[...]
Dec 20 16:06:54 ipa1.example.com krb5kdc[15517](info): AS_REQ (8 etypes {18 17 
20 19 16 23 25 26}) 141.51.X.Y: NEEDED_PREAUTH: WELLKNOWN/anonym...@example.com 
for krbtgt/example@example.com, Additional pre-authentication required
Dec 20 16:06:54 ipa1.example.com krb5kdc[15517](info): closing down fd 11
Dec 20 16:06:54 ipa1.example.com krb5kdc[15518](info): AS_REQ (8 etypes {18 17 
20 19 16 23 25 26}) 141.51.X.Y: KDC_RETURN_PADATA: 
WELLKNOWN/anonym...@example.com for krbtgt/example@example.com, Failed to 
verify own certificate (depth 0): certificate has expired
Dec 20 16:06:54 ipa1.example.com krb5kdc[15518](info): closing down fd 11
---

--- ipa-checkcerts.py
IPA version 4.5.4-10.el7.centos.3
Check CA status
Check tracking
Check NSS trust
Check dates
Checking certificates in CS.cfg
Comparing certificates to requests in LDAP
Checking RA certificate
Checking authorities
Checking host keytab
Validating certificates
Checking renewal master
End-to-end cert API test
Checking permissions and ownership
Failures:
Unable to find request for serial 268304391
Unable to find request for serial 268304394
Unable to find request for serial 268304393
Unable to find request for serial 268304392
Subject O=EXAMPLE.COM,CN=ipa2.example.com and template subject 
CN=ipa1.example.com,O=EXAMPLE.COM do not match for serial 57
---

--- ipa pkinit-status --all
-
2 servers matched
-
  Server name: ipa2.example.com
  PKINIT status: enabled

  Server name: ipa1.example.com
  PKINIT status: enabled

Number of entries returned 2


To my understanding, proper certificate exchange between my two servers 
ceased working at some point. How do i track this down and fix it?



Mit freundlichen Gruessen/With best regards,

--Daniel.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA/Dogtag - Slow host deletion due to certificate pagination

2018-12-20 Thread Florence Blanc-Renaud via FreeIPA-users


On 12/20/18 3:49 PM, Jared Ledvina via FreeIPA-users wrote:

Hi folks,

I recently posted a thread to pki-users, 
https://www.redhat.com/archives/pki-users/2018-December/msg3.html . Working 
with 'cipherboy' on IRC in #dogtag-pki, we narrowed the issue down to the 
searches that Dogtag performs against a VLV index/search. These are being 
paginated to 2,000 entries. I've since, opened up: 
https://bugzilla.redhat.com/show_bug.cgi?id=1658280 but, haven't been able to 
figure out a solution. I'm hoping that someone on this list might be able to 
troubleshoot further with me on this.

Has anyone looked at this before? So far, I'm unable to determine where the 
2,000 paging size is getting set.

The linked bugzilla issue should have a bunch of necessary details but, I'm 
happy to provide any additional details that might help.

Thanks,
Jared



Hi,

the size and time limits can be defined at multiple levels:

* per user:
dn: uid=,cn=users,cn=accounts,$BASEDN
nsSizeLimit:
nsTimeLimit:
nsLookThroughLimit:
nsPagedLookThroughLimit:
nsPagedSizeLimit:
nsIdleTimeout:
nsIDListScanLimit:
nsPagedIDListScanLimit:
The meaning for each attribute can be found in [1].

* if it's not defined at the user level, the global ds settings apply
dn: cn=config
nsslapd-sizelimit:
nsslapd-timelimit:
nsslapd-pagedsizelimit:
nsslapd-idletimeout:
nsslapd-anonlimitsdn: cn=anonymous-limits,cn=etc,$BASEDN (points to an 
entry containing limits for anonymous operations)

The meaning for each attribute can be found in [1].

* settings per DS database:
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
nsslapd-lookthroughlimit:
nsslapd-idlistscanlimit:
nsslapd-pagedlookthroughlimit:
nsslapd-pagedidlistscanlimit:
nsslapd-rangelookthroughlimit:
The meaning for each attribute can be found in [2].

* settings at IPA level:
dn: cn=ipaconfig,cn=etc,$BASEDN
ipaSearchRecordsLimit:
ipaSearchTimeLimit:

If you find your 2000 value in one of those attributes, you will be able 
to understand which limit applies.


HTH,
flo

[1] 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/operational_attributes_special_attributes_and_special_object_classes
[2] 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/core_server_configuration_reference#cnconfig
[3] 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/database_plug_in_attributes#Database_Attributes_under_cnconfig_cnldbm_database_cnplugins_cnconfig

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Limits exceeded for this query

2018-12-20 Thread lune voo via FreeIPA-users

Re Florence.

I performed the following command :

ipa config-mod --searchtimelimit=5


It solved this "problem".

May I ask what can be the impacts on increasing searchtimelimit please ?


Best regards.


Lune




Le jeu. 20 déc. 2018 à 12:37, Florence Blanc-Renaud  a
écrit :

> Hi,
>
> based on the err code err=3 I can see that I was wrong, it's not a size
> limit but rather a time limit issue. It looks like the LDAP server is
> busy after the modification on the cn= entry and takes more
> than 33sec to answer.
>
> The default search time limit is 2 seconds at IPA level:
> dn: cn=ipaConfig,cn=etc,$BASEDN
> ipaSearchTimeLimit: 2
>
> There is also a search time limit set at 389-ds level:
> dn: cn=config
> nsslapd-timelimit: 3600
>
> and another one can be set per-user:
> dn: uid=,cn=users,cn=accounts,$BASEDN
> nsTimeLimit: 
>
> Is there anything in the error log of 389-ds at the same time?
>
> Note that IPA 3.0.0 is quite old and we did improvements related to
> group management in more recent versions (for instance [1] or [2]).
> The failing search may simply be an internal search in order to get the
> size and time limits, needed to create the search that will check the
> content of the entry after the MOD has been done.
>
> flo
>
> [1] https://pagure.io/freeipa/issue/4965
> [2] https://pagure.io/freeipa/issue/4947
>
> On 12/20/18 11:38 AM, lune voo via FreeIPA-users wrote:
> > I tried to perform an ldapsearch using the same kind of command :
> >
> > ldapsearch -x -D "cn=Directory Manager" \
> >>   -h  \
> >>   -p 389 \
> >>   -W \
> >>   -b "cn=ipaconfig,cn=etc,dc=" \
> >>   -s sub \
> >> objectclass=*
> > Enter LDAP Password:
> >
> >
> > I got this result immediately :
> > # extended LDIF
> > #
> > # LDAPv3
> > # base > with scope subtree
> > # filter: objectclass=*
> > # requesting: ALL
> > #
> >
> > # ipaConfig, etc, 
> > dn: cn=ipaConfig,cn=etc,dc=
> > objectClass: nsContainer
> > objectClass: top
> > objectClass: ipaGuiConfig
> > objectClass: ipaConfigObject
> > ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
> > ipaGroupSearchFields: cn,description
> > ipaSearchTimeLimit: 2
> > ipaSearchRecordsLimit: 100
> > ipaHomesRootDir: /home
> > ipaDefaultLoginShell: /bin/sh
> > ipaDefaultPrimaryGroup: users
> > ipaMaxUsernameLength: 64
> > ipaPwdExpAdvNotify: 4
> > ipaGroupObjectClasses: top
> > ipaGroupObjectClasses: groupofnames
> > ipaGroupObjectClasses: nestedgroup
> > ipaGroupObjectClasses: ipausergroup
> > ipaGroupObjectClasses: ipaobject
> > ipaUserObjectClasses: top
> > ipaUserObjectClasses: person
> > ipaUserObjectClasses: organizationalperson
> > ipaUserObjectClasses: inetorgperson
> > ipaUserObjectClasses: inetuser
> > ipaUserObjectClasses: posixaccount
> > ipaUserObjectClasses: krbprincipalaux
> > ipaUserObjectClasses: krbticketpolicyaux
> > ipaUserObjectClasses: ipaobject
> > ipaUserObjectClasses: ipasshuser
> > ipaDefaultEmailDomain: 
> > ipaMigrationEnabled: FALSE
> > ipaConfigString: AllowNThash
> > ipaSELinuxUserMapOrder:
> > guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c102
> >   3$unconfined_u:s0-s0:c0.c1023
> > ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023
> > cn: ipaConfig
> > ipaCertificateSubjectBase: O=
> > ipaKrbAuthzData: MS-PAC
> >
> > # search result
> > search: 2
> > result: 0 Success
> >
> > # numResponses: 2
> > # numEntries: 1
> >
> > This query is fine and fast.
> >
> > Best regards.
> >
> > Lune
> >
> >
> > Le jeu. 20 déc. 2018 à 11:25, lune voo  > > a écrit :
> >
> > Here is the value of nsslapd-sizelimit
> >
> > nsslapd-sizelimit: 2000
> >
> > For the anonymous queries, we disabled them long time ago.
> >
> > If I understand well, the problem comes from this search :
> > SRCH base="cn=ipaconfig,cn=etc,dc=" scope=0
> > filter="(objectClass=*)" attrs=ALL
> >
> > Do you know why this search is performed once the member user has
> > been removed from the group ?
> >
> > Lune
> >
> > Le jeu. 20 déc. 2018 à 11:08, lune voo  > > a écrit :
> >
> > Hello Florence.
> >
> > Can you see in 389-ds logs which operation is triggering the
> > size-limit
> > error? In /var/log/dirsrv/slapd-domXXX/access, you will find
> > a line with
> > RESULT err=4, note the conn=xx and op=yy values, then look
> > above for a
> > line with conn=xx op=yy SRCH and finally another line above
> > with conn=xx
> > op=0 BIND. Please paste the 3 lines for analysis.
> >
> >
> > How do you identify the lines concerned please ?
> > Is "conn" a unique ID of the connection ?
> >
> > I find this concerning the connection 33725735 that I think I am
> > using :
> > 674:[20/Dec/2018:10:30:34 +0100] conn=33725735 fd=64 slot=64
> > connection from  to 
> > 715:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 BIND dn=""
>

[Freeipa-users] Re: Single Sign On (SSO) SSH via IP Address

2018-12-20 Thread Bryan Mesich via FreeIPA-users

On Wed, Dec 19, 2018 at 09:41:49PM -0600, Bryan Mesich via FreeIPA-users wrote:
> On Wed, Dec 19, 2018 at 09:18:35PM -0600, Bryan Mesich via FreeIPA-users 
> wrote:

[snip...]

> I was able to reproduce the problem on my end.  I forgot that Kerberos
> can canonicalize host names.  If I set "dns_canonicalize_hostname =
> false" under the [libdefaults] section (in krb5.conf on client), I get
> the same problem:
> 
> debug1: Unspecified GSS failure.  Minor code may provide more
> information Server host/10.10.128...@xx..com not found in Kerberos 
> database
> 
> Try setting it to true and see what happens.

GSSAPITrustDns=yes in ssh_conf should also do the trick.  You can decide
where you want the canonicalization to occur, ssh or krb5.

Bryan

> 
> Bryan
-- 
Bryan Mesich
Sr. System Administrator
DIGI-KEY ELECTRONICS
701 Brooks Ave. South
Thief River Falls, MN 56701 USA
bryan.mes...@digikey.com
218.681.8000 x6104

Powered by Linux 3.10.0-862.6.3.el7.x86_64
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] FreeIPA/Dogtag - Slow host deletion due to certificate pagination

2018-12-20 Thread Jared Ledvina via FreeIPA-users

Hi folks,

I recently posted a thread to pki-users, 
https://www.redhat.com/archives/pki-users/2018-December/msg3.html . Working 
with 'cipherboy' on IRC in #dogtag-pki, we narrowed the issue down to the 
searches that Dogtag performs against a VLV index/search. These are being 
paginated to 2,000 entries. I've since, opened up: 
https://bugzilla.redhat.com/show_bug.cgi?id=1658280 but, haven't been able to 
figure out a solution. I'm hoping that someone on this list might be able to 
troubleshoot further with me on this. 

Has anyone looked at this before? So far, I'm unable to determine where the 
2,000 paging size is getting set. 

The linked bugzilla issue should have a bunch of necessary details but, I'm 
happy to provide any additional details that might help. 

Thanks,
Jared


-- 
  Jared Ledvina
  ja...@techsmix.net
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: new replica does not post properly in ipa_check_consistency

2018-12-20 Thread Grant Janssen via FreeIPA-users

I never thought to dissect the ipa_check_consistency script.
I wasn’t going to add the SRV record until everything tested perfectly - didn’t 
want authorizations going
to server that wasn’t functioning.

added the SRV record.  now THAT was an easy fix.

grant@ef-idm03:~[20181219-11:37][#111]$ ipa_check_consistency -d 
PRODUCTION.EFILM.COM<http://PRODUCTION.EFILM.COM> -W 
FreeIPA servers:ef-idm01ef-idm02ef-idm03STATE
=
Active Users129 129 129 OK
Stage Users 7   7   7   OK
Preserved Users 0   0   0   OK
User Groups 22  22  22  OK
Hosts   158 158 158 OK
Host Groups 16  16  16  OK
HBAC Rules  5   5   5   OK
SUDO Rules  14  14  14  OK
DNS Zones   ERROR   ERROR   ERROR   OK
LDAP Conflicts  NO  NO  NO  OK
Ghost Replicas  NO  NO  NO  OK
Anonymous BIND  YES YES YES OK
Replication Status  ef-idm02 0  ef-idm01 0  ef-idm01 0
ef-idm03 0
=
grant@ef-idm03:~[20181220-5:42][#112]$

thanx
& merry christmas

- grant


This e-mail and any attachments are intended only for use by the addressee(s) 
named herein and may contain confidential information. If you are not the 
intended recipient of this e-mail, you are hereby notified any dissemination, 
distribution or copying of this email and any attachments is strictly 
prohibited. If you receive this email in error, please immediately notify the 
sender by return email and permanently delete the original, any copy and any 
printout thereof. The integrity and security of e-mail cannot be guaranteed.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Vault feature for AD users

2018-12-20 Thread Ronald Wimmer via FreeIPA-users


Is it true that this feature is only available to native ipa users?

On 30.11.18 09:42, Ronald Wimmer via FreeIPA-users wrote:
Is there any possibility to use the vault feature for external (AD) 
users?

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org

Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Limits exceeded for this query

2018-12-20 Thread Florence Blanc-Renaud via FreeIPA-users


Hi,

based on the err code err=3 I can see that I was wrong, it's not a size 
limit but rather a time limit issue. It looks like the LDAP server is 
busy after the modification on the cn= entry and takes more 
than 33sec to answer.


The default search time limit is 2 seconds at IPA level:
dn: cn=ipaConfig,cn=etc,$BASEDN
ipaSearchTimeLimit: 2

There is also a search time limit set at 389-ds level:
dn: cn=config
nsslapd-timelimit: 3600

and another one can be set per-user:
dn: uid=,cn=users,cn=accounts,$BASEDN
nsTimeLimit: 

Is there anything in the error log of 389-ds at the same time?

Note that IPA 3.0.0 is quite old and we did improvements related to 
group management in more recent versions (for instance [1] or [2]).
The failing search may simply be an internal search in order to get the 
size and time limits, needed to create the search that will check the 
content of the entry after the MOD has been done.


flo

[1] https://pagure.io/freeipa/issue/4965
[2] https://pagure.io/freeipa/issue/4947

On 12/20/18 11:38 AM, lune voo via FreeIPA-users wrote:

I tried to perform an ldapsearch using the same kind of command :

ldapsearch -x -D "cn=Directory Manager" \

   -h  \
   -p 389 \
   -W \
   -b "cn=ipaconfig,cn=etc,dc=" \
   -s sub \
objectclass=*

Enter LDAP Password:


I got this result immediately :
# extended LDIF
#
# LDAPv3
# base > with scope subtree
# filter: objectclass=*
# requesting: ALL
#

# ipaConfig, etc, 
dn: cn=ipaConfig,cn=etc,dc=
objectClass: nsContainer
objectClass: top
objectClass: ipaGuiConfig
objectClass: ipaConfigObject
ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
ipaGroupSearchFields: cn,description
ipaSearchTimeLimit: 2
ipaSearchRecordsLimit: 100
ipaHomesRootDir: /home
ipaDefaultLoginShell: /bin/sh
ipaDefaultPrimaryGroup: users
ipaMaxUsernameLength: 64
ipaPwdExpAdvNotify: 4
ipaGroupObjectClasses: top
ipaGroupObjectClasses: groupofnames
ipaGroupObjectClasses: nestedgroup
ipaGroupObjectClasses: ipausergroup
ipaGroupObjectClasses: ipaobject
ipaUserObjectClasses: top
ipaUserObjectClasses: person
ipaUserObjectClasses: organizationalperson
ipaUserObjectClasses: inetorgperson
ipaUserObjectClasses: inetuser
ipaUserObjectClasses: posixaccount
ipaUserObjectClasses: krbprincipalaux
ipaUserObjectClasses: krbticketpolicyaux
ipaUserObjectClasses: ipaobject
ipaUserObjectClasses: ipasshuser
ipaDefaultEmailDomain: 
ipaMigrationEnabled: FALSE
ipaConfigString: AllowNThash
ipaSELinuxUserMapOrder: 
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c102

  3$unconfined_u:s0-s0:c0.c1023
ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023
cn: ipaConfig
ipaCertificateSubjectBase: O=
ipaKrbAuthzData: MS-PAC

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

This query is fine and fast.

Best regards.

Lune


Le jeu. 20 déc. 2018 à 11:25, lune voo > a écrit :


Here is the value of nsslapd-sizelimit

nsslapd-sizelimit: 2000

For the anonymous queries, we disabled them long time ago.

If I understand well, the problem comes from this search :
SRCH base="cn=ipaconfig,cn=etc,dc=" scope=0
filter="(objectClass=*)" attrs=ALL

Do you know why this search is performed once the member user has
been removed from the group ?

Lune

Le jeu. 20 déc. 2018 à 11:08, lune voo mailto:lune.voo1...@gmail.com>> a écrit :

Hello Florence.

Can you see in 389-ds logs which operation is triggering the
size-limit
error? In /var/log/dirsrv/slapd-domXXX/access, you will find
a line with
RESULT err=4, note the conn=xx and op=yy values, then look
above for a
line with conn=xx op=yy SRCH and finally another line above
with conn=xx
op=0 BIND. Please paste the 3 lines for analysis.


How do you identify the lines concerned please ?
Is "conn" a unique ID of the connection ?

I find this concerning the connection 33725735 that I think I am
using :
674:[20/Dec/2018:10:30:34 +0100] conn=33725735 fd=64 slot=64
connection from  to 
715:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 BIND dn=""
method=sasl version=3 mech=GSSAPI
716:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 RESULT
err=14 tag=97 nentries=0 etime=0, SASL bind in progress
717:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=1 BIND dn=""
method=sasl version=3 mech=GSSAPI
718:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=1 RESULT
err=14 tag=97 nentries=0 etime=0, SASL bind in progress
719:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=2 BIND dn=""
method=sasl version=3 mech=GSSAPI
720:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=2 RESULT err=0
tag=97 nentries=0 etime=0
dn="uid=,cn=users,cn=accounts,dc="
721:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=3 MOD
dn="cn=,cn=groups,cn=acc

[Freeipa-users] Re: Moving IPA master to a new server fails to start krb5kdc

2018-12-20 Thread Kees Bakker via FreeIPA-users

On 19-12-18 12:06, Kees Bakker via FreeIPA-users wrote:
> On 18-12-18 17:50, Florence Blanc-Renaud wrote:
> [...]
>> If you have a spare machine you can also use replication, and create a 
>> replica of your current master with all the needed services (CA, KRA, DNS if 
>> needed).
>> If you really need to keep the same hostname, then you will need a spare 
>> machine:
>> 1. create serverB as a replica of serverA on your spare machine. Do not 
>> forget to promote serverB as CA renewal master and CRL master [2].
>> 2. decommission serverA with (on serverA) ipa-server-install --uninstall and 
>> (on serverB) ipa-replica-manage del serverA --clean
>> 3. provision your new hardware with hostname=serverA, install serverA as a 
>> replica of serverB.
>> I would advise to keep serverB as it will provide redundancy.
>>
>> This wiki [3] also explains the preferred paths depending on your situation.
> I have read that document too. First I want to give it another try. If it
> fails again I will follow advice described above.
>
> Thanks for your help.
>
>> HTH,
>> flo
>>
>>
>> [1] 
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/#backup-restore
>> [2] https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master
>> [3] https://www.freeipa.org/page/Backup_and_Restore
>>

Just to let you know, I have given up with my "rsync" procedure. I am now
following the steps above. Well, except step3, because I didn't want to add
even more hardware in the process (the "spare machine" mentioned above).

Step 1 is completed. Promotion of CA renewal and CRL master is done.

I have a remaining question.
What do I do with all the IPA clients that point to serverA? At some point I
want to execute step 2, and shut off that system. I briefly looked at the files
in /etc and found these (alblas is my serverA):

/etc/sssd/sssd.conf:ipa_server = _srv_, alblas.ghs.nl
/etc/ipa/default.conf:server = alblas.ghs.nl
/etc/ipa/default.conf:xmlrpc_uri = https://alblas.ghs.nl/ipa/xml
/etc/ntp.conf:server alblas.ghs.nl
/etc/ldap/ldap.conf:URI ldaps://alblas.ghs.nl

Do I have to visit each client and modify these files? Anything else?
-- 
Kees
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Limits exceeded for this query

2018-12-20 Thread lune voo via FreeIPA-users

I tried to perform an ldapsearch using the same kind of command :

ldapsearch -x -D "cn=Directory Manager" \
>   -h  \
>   -p 389 \
>   -W \
>   -b "cn=ipaconfig,cn=etc,dc=" \
>   -s sub \
> objectclass=*
Enter LDAP Password:


I got this result immediately :
# extended LDIF
#
# LDAPv3
# base > with scope subtree
# filter: objectclass=*
# requesting: ALL
#

# ipaConfig, etc, 
dn: cn=ipaConfig,cn=etc,dc=
objectClass: nsContainer
objectClass: top
objectClass: ipaGuiConfig
objectClass: ipaConfigObject
ipaUserSearchFields: uid,givenname,sn,telephonenumber,ou,title
ipaGroupSearchFields: cn,description
ipaSearchTimeLimit: 2
ipaSearchRecordsLimit: 100
ipaHomesRootDir: /home
ipaDefaultLoginShell: /bin/sh
ipaDefaultPrimaryGroup: users
ipaMaxUsernameLength: 64
ipaPwdExpAdvNotify: 4
ipaGroupObjectClasses: top
ipaGroupObjectClasses: groupofnames
ipaGroupObjectClasses: nestedgroup
ipaGroupObjectClasses: ipausergroup
ipaGroupObjectClasses: ipaobject
ipaUserObjectClasses: top
ipaUserObjectClasses: person
ipaUserObjectClasses: organizationalperson
ipaUserObjectClasses: inetorgperson
ipaUserObjectClasses: inetuser
ipaUserObjectClasses: posixaccount
ipaUserObjectClasses: krbprincipalaux
ipaUserObjectClasses: krbticketpolicyaux
ipaUserObjectClasses: ipaobject
ipaUserObjectClasses: ipasshuser
ipaDefaultEmailDomain: 
ipaMigrationEnabled: FALSE
ipaConfigString: AllowNThash
ipaSELinuxUserMapOrder:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c102
 3$unconfined_u:s0-s0:c0.c1023
ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023
cn: ipaConfig
ipaCertificateSubjectBase: O=
ipaKrbAuthzData: MS-PAC

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

This query is fine and fast.

Best regards.

Lune


Le jeu. 20 déc. 2018 à 11:25, lune voo  a écrit :

> Here is the value of nsslapd-sizelimit
>
> nsslapd-sizelimit: 2000
>
> For the anonymous queries, we disabled them long time ago.
>
> If I understand well, the problem comes from this search :
> SRCH base="cn=ipaconfig,cn=etc,dc=" scope=0
> filter="(objectClass=*)" attrs=ALL
>
> Do you know why this search is performed once the member user has been
> removed from the group ?
>
> Lune
>
> Le jeu. 20 déc. 2018 à 11:08, lune voo  a écrit :
>
>> Hello Florence.
>>
>> Can you see in 389-ds logs which operation is triggering the size-limit
>>> error? In /var/log/dirsrv/slapd-domXXX/access, you will find a line with
>>> RESULT err=4, note the conn=xx and op=yy values, then look above for a
>>> line with conn=xx op=yy SRCH and finally another line above with conn=xx
>>> op=0 BIND. Please paste the 3 lines for analysis.
>>>
>>
>> How do you identify the lines concerned please ?
>> Is "conn" a unique ID of the connection ?
>>
>> I find this concerning the connection 33725735 that I think I am using :
>> 674:[20/Dec/2018:10:30:34 +0100] conn=33725735 fd=64 slot=64 connection
>> from  to 
>> 715:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 BIND dn=""
>> method=sasl version=3 mech=GSSAPI
>> 716:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 RESULT err=14 tag=97
>> nentries=0 etime=0, SASL bind in progress
>> 717:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=1 BIND dn=""
>> method=sasl version=3 mech=GSSAPI
>> 718:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=1 RESULT err=14 tag=97
>> nentries=0 etime=0, SASL bind in progress
>> 719:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=2 BIND dn=""
>> method=sasl version=3 mech=GSSAPI
>> 720:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=2 RESULT err=0 tag=97
>> nentries=0 etime=0 dn="uid=,cn=users,cn=accounts,dc="
>> 721:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=3 MOD
>> dn="cn=,cn=groups,cn=accounts,dc="
>> 725:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=3 RESULT err=0 tag=103
>> nentries=0 etime=0
>> 735:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=4 SRCH
>> base="cn=ipaconfig,cn=etc,dc=" scope=0 filter="(objectClass=*)"
>> attrs=ALL
>> 753:[20/Dec/2018:10:31:07 +0100] conn=33725735 op=4 RESULT err=3 tag=101
>> nentries=0 etime=33
>> 841:[20/Dec/2018:10:31:08 +0100] conn=33725735 op=5 UNBIND
>> 842:[20/Dec/2018:10:31:08 +0100] conn=33725735 op=5 fd=64 closed - U1
>>
>> I cannot find anything related to conn=33725735 between line #735 and
>> line #753.
>> So I find that there are 3 errors, but I don't have details of these
>> errors.
>>
>>
>> The size limits are configured at multiple levels:
>>> - at IPA level: with ipa config-show, you can see the settings that IPA
>>> is using for all the queries triggered by ipa *-find commands.
>>> - at 389-ds level: the attribute nsslapd-sizelimit of the entry
>>> cn=config is also limiting the number of returned entries
>>> - at 389-ds level: the attributes nsSizeLimit and nsLookThroughLimit of
>>>
>> the entry cn=anonymous-limits,cn=etc,$BASEDN limit the number of
>>> returned entries for anonymous queries
>>> - it is also possible to configure per-user limits, for instance in
>>> uid=user,cn=users,cn=accounts,$BASEDN with the attributes nsSizeLimit
>>> nsLookThroughL

[Freeipa-users] Re: Limits exceeded for this query

2018-12-20 Thread lune voo via FreeIPA-users

Here is the value of nsslapd-sizelimit

nsslapd-sizelimit: 2000

For the anonymous queries, we disabled them long time ago.

If I understand well, the problem comes from this search :
SRCH base="cn=ipaconfig,cn=etc,dc=" scope=0
filter="(objectClass=*)" attrs=ALL

Do you know why this search is performed once the member user has been
removed from the group ?

Lune

Le jeu. 20 déc. 2018 à 11:08, lune voo  a écrit :

> Hello Florence.
>
> Can you see in 389-ds logs which operation is triggering the size-limit
>> error? In /var/log/dirsrv/slapd-domXXX/access, you will find a line with
>> RESULT err=4, note the conn=xx and op=yy values, then look above for a
>> line with conn=xx op=yy SRCH and finally another line above with conn=xx
>> op=0 BIND. Please paste the 3 lines for analysis.
>>
>
> How do you identify the lines concerned please ?
> Is "conn" a unique ID of the connection ?
>
> I find this concerning the connection 33725735 that I think I am using :
> 674:[20/Dec/2018:10:30:34 +0100] conn=33725735 fd=64 slot=64 connection
> from  to 
> 715:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 BIND dn="" method=sasl
> version=3 mech=GSSAPI
> 716:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 RESULT err=14 tag=97
> nentries=0 etime=0, SASL bind in progress
> 717:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=1 BIND dn="" method=sasl
> version=3 mech=GSSAPI
> 718:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=1 RESULT err=14 tag=97
> nentries=0 etime=0, SASL bind in progress
> 719:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=2 BIND dn="" method=sasl
> version=3 mech=GSSAPI
> 720:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=2 RESULT err=0 tag=97
> nentries=0 etime=0 dn="uid=,cn=users,cn=accounts,dc="
> 721:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=3 MOD
> dn="cn=,cn=groups,cn=accounts,dc="
> 725:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=3 RESULT err=0 tag=103
> nentries=0 etime=0
> 735:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=4 SRCH
> base="cn=ipaconfig,cn=etc,dc=" scope=0 filter="(objectClass=*)"
> attrs=ALL
> 753:[20/Dec/2018:10:31:07 +0100] conn=33725735 op=4 RESULT err=3 tag=101
> nentries=0 etime=33
> 841:[20/Dec/2018:10:31:08 +0100] conn=33725735 op=5 UNBIND
> 842:[20/Dec/2018:10:31:08 +0100] conn=33725735 op=5 fd=64 closed - U1
>
> I cannot find anything related to conn=33725735 between line #735 and
> line #753.
> So I find that there are 3 errors, but I don't have details of these
> errors.
>
>
> The size limits are configured at multiple levels:
>> - at IPA level: with ipa config-show, you can see the settings that IPA
>> is using for all the queries triggered by ipa *-find commands.
>> - at 389-ds level: the attribute nsslapd-sizelimit of the entry
>> cn=config is also limiting the number of returned entries
>> - at 389-ds level: the attributes nsSizeLimit and nsLookThroughLimit of
>>
> the entry cn=anonymous-limits,cn=etc,$BASEDN limit the number of
>> returned entries for anonymous queries
>> - it is also possible to configure per-user limits, for instance in
>> uid=user,cn=users,cn=accounts,$BASEDN with the attributes nsSizeLimit
>> nsLookThroughLimit nsPagedLookThroughLimit and nsPagedSizeLimit
>>
>
> config-show gave me this :
>  Search time limit: 2
>  Search size limit: 100
>
> I need to check the values of "nsslapd-sizelimit" and "nsSizeLimit" I
> currently have.
> Will come back asap.
>
> Lune
>
> Le mer. 19 déc. 2018 à 21:59, lune voo  a écrit :
>
>> Hello Florence.
>>
>> Going to check that tomorrow and add these lines.
>>
>> Thanks for this first answer.
>>
>> Lune
>>
>> Le mer. 19 déc. 2018 à 20:27, Florence Blanc-Renaud  a
>> écrit :
>>
>>> On 12/19/18 12:15 PM, lune voo via FreeIPA-users wrote:
>>> > Hello everyone.
>>> >
>>> > I send you this mail because I have a problem with an ipa
>>> > group-remove-member command which ends up with the following error
>>> message :
>>> > "Limits exceeded for this query".
>>> >
>>> > I'm using IPA 3.0.0.
>>> > The group for which I want to remove a user contains other groups also
>>> > (281).
>>> >
>>> > I was wondering how I could solve this problem ?
>>> >
>>> > I tried to play with the configuration as described here :
>>> >
>>> https://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/searches.html
>>> >
>>> > I tried to increase both limits but it did not solve the problem.
>>> > I guess as I'm not doing a search but group remove member, this
>>> > parameters are not used maybe ?
>>> >
>>> > Thanks for your help o/
>>> >
>>> > Best regards.
>>> >
>>> > Lune.
>>> >
>>> > ___
>>> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> > To unsubscribe send an email to
>>> freeipa-users-le...@lists.fedorahosted.org
>>> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> > List Guidelines:
>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> > List Archives:
>>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost

[Freeipa-users] Re: Limits exceeded for this query

2018-12-20 Thread lune voo via FreeIPA-users

Hello Florence.

Can you see in 389-ds logs which operation is triggering the size-limit
> error? In /var/log/dirsrv/slapd-domXXX/access, you will find a line with
> RESULT err=4, note the conn=xx and op=yy values, then look above for a
> line with conn=xx op=yy SRCH and finally another line above with conn=xx
> op=0 BIND. Please paste the 3 lines for analysis.
>

How do you identify the lines concerned please ?
Is "conn" a unique ID of the connection ?

I find this concerning the connection 33725735 that I think I am using :
674:[20/Dec/2018:10:30:34 +0100] conn=33725735 fd=64 slot=64 connection
from  to 
715:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
716:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
717:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
718:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
719:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
720:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=2 RESULT err=0 tag=97
nentries=0 etime=0 dn="uid=,cn=users,cn=accounts,dc="
721:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=3 MOD
dn="cn=,cn=groups,cn=accounts,dc="
725:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=3 RESULT err=0 tag=103
nentries=0 etime=0
735:[20/Dec/2018:10:30:34 +0100] conn=33725735 op=4 SRCH
base="cn=ipaconfig,cn=etc,dc=" scope=0 filter="(objectClass=*)"
attrs=ALL
753:[20/Dec/2018:10:31:07 +0100] conn=33725735 op=4 RESULT err=3 tag=101
nentries=0 etime=33
841:[20/Dec/2018:10:31:08 +0100] conn=33725735 op=5 UNBIND
842:[20/Dec/2018:10:31:08 +0100] conn=33725735 op=5 fd=64 closed - U1

I cannot find anything related to conn=33725735 between line #735 and line
#753.
So I find that there are 3 errors, but I don't have details of these errors.


The size limits are configured at multiple levels:
> - at IPA level: with ipa config-show, you can see the settings that IPA
> is using for all the queries triggered by ipa *-find commands.
> - at 389-ds level: the attribute nsslapd-sizelimit of the entry
> cn=config is also limiting the number of returned entries
> - at 389-ds level: the attributes nsSizeLimit and nsLookThroughLimit of
>
the entry cn=anonymous-limits,cn=etc,$BASEDN limit the number of
> returned entries for anonymous queries
> - it is also possible to configure per-user limits, for instance in
> uid=user,cn=users,cn=accounts,$BASEDN with the attributes nsSizeLimit
> nsLookThroughLimit nsPagedLookThroughLimit and nsPagedSizeLimit
>

config-show gave me this :
 Search time limit: 2
 Search size limit: 100

I need to check the values of "nsslapd-sizelimit" and "nsSizeLimit" I
currently have.
Will come back asap.

Lune

Le mer. 19 déc. 2018 à 21:59, lune voo  a écrit :

> Hello Florence.
>
> Going to check that tomorrow and add these lines.
>
> Thanks for this first answer.
>
> Lune
>
> Le mer. 19 déc. 2018 à 20:27, Florence Blanc-Renaud  a
> écrit :
>
>> On 12/19/18 12:15 PM, lune voo via FreeIPA-users wrote:
>> > Hello everyone.
>> >
>> > I send you this mail because I have a problem with an ipa
>> > group-remove-member command which ends up with the following error
>> message :
>> > "Limits exceeded for this query".
>> >
>> > I'm using IPA 3.0.0.
>> > The group for which I want to remove a user contains other groups also
>> > (281).
>> >
>> > I was wondering how I could solve this problem ?
>> >
>> > I tried to play with the configuration as described here :
>> >
>> https://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/searches.html
>> >
>> > I tried to increase both limits but it did not solve the problem.
>> > I guess as I'm not doing a search but group remove member, this
>> > parameters are not used maybe ?
>> >
>> > Thanks for your help o/
>> >
>> > Best regards.
>> >
>> > Lune.
>> >
>> > ___
>> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> > To unsubscribe send an email to
>> freeipa-users-le...@lists.fedorahosted.org
>> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives:
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>> >
>>
>> Hi,
>>
>> when you are running ipa group-remove-member, are you authenticated as
>> admin or as another user?
>>
>> Can you see in 389-ds logs which operation is triggering the size-limit
>> error? In /var/log/dirsrv/slapd-domXXX/access, you will find a line with
>> RESULT err=4, note the conn=xx and op=yy values, then look above for a
>> line with conn=xx op=yy SRCH and finally another line above with conn=xx
>> op=0 BIND. Please paste the 3 lines for analysis.
>>
>> The size limits are configured at multiple levels:
>> - at IPA level: with ipa config-show, y

[Freeipa-users] Re: new replica does not post properly in ipa_check_consistency

2018-12-20 Thread Florence Blanc-Renaud via FreeIPA-users


On 12/19/18 8:39 PM, Grant Janssen via FreeIPA-users wrote:

   New replica looks to be fully joined.  I can add users, and I have verified 
by log examination
that the new replica is actually the server adding the user.

   I cannot detect any issues, BUT the 3rd replica does not appear as a column 
when I execute the
ipa_check_consistency script.

grant@ef-idm03:~[20181219-11:35][#103]$ ipa-replica-manage list
ef-idm03.production.efilm.com: master
ef-idm02.production.efilm.com: master
ef-idm01.production.efilm.com: master
grant@ef-idm03:~[20181219-11:35][#104]$ ipa_check_consistency -d 
PRODUCTION.EFILM.COM -W 
FreeIPA servers:ef-idm01ef-idm02STATE
=
Active Users129 129 OK
Stage Users 7   7   OK
Preserved Users 0   0   OK
User Groups 22  22  OK
Hosts   158 158 OK
Host Groups 16  16  OK
HBAC Rules  5   5   OK
SUDO Rules  14  14  OK
DNS Zones   ERROR   ERROR   OK
LDAP Conflicts  NO  NO  OK
Ghost Replicas  NO  NO  OK
Anonymous BIND  YES YES OK
Replication Status  ef-idm02 0  ef-idm01 0
 ef-idm03 0
=
grant@ef-idm03:~[20181219-11:35][#105]$ ipa user_find | grep entries
Number of entries returned 129
grant@ef-idm03:~[20181219-11:35][#106]$ ipa group_find | grep entries
Number of entries returned 22
grant@ef-idm03:~[20181219-11:35][#107]$ ipa host_find | grep entries
Number of entries returned 155
grant@ef-idm03:~[20181219-11:36][#108]$ ipa hostgroup_find | grep entries
Number of entries returned 16
grant@ef-idm03:~[20181219-11:36][#109]$ ipa hbacrule-find | grep entries
Number of entries returned 5
grant@ef-idm03:~[20181219-11:37][#110]$ ipa sudorule-find | grep entries
Number of entries returned 14
grant@ef-idm03:~[20181219-11:37][#111]$

what does this indicate?

Hi,
(disclaimer: I am not familiar with ipa-check-consistency)
I had a quick look at the code for ipa_check_consistency. If the list of 
servers is not provided in the command line, they are found in the DNS 
with the records for _ldap._tcp of the domain.

Can you check the output of
# dig +short -t SRV _ldap._tcp.$domain.

flo


thanx

- grant

This e-mail and any attachments are intended only for use by the addressee(s) 
named herein and may contain confidential information. If you are not the 
intended recipient of this e-mail, you are hereby notified any dissemination, 
distribution or copying of this email and any attachments is strictly 
prohibited. If you receive this email in error, please immediately notify the 
sender by return email and permanently delete the original, any copy and any 
printout thereof. The integrity and security of e-mail cannot be guaranteed.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: IPA managed autofs mount timeout

[Freeipa-users] IPA managed autofs mount timeout

[Freeipa-users] Re: dnskeysync stacktrace

[Freeipa-users] Versleuteld bericht

[Freeipa-users] Re: Trouble with pki-tomcat

[Freeipa-users] Re: Web UI login/certificate issues, IPA 4.5.4

[Freeipa-users] Re: FreeIPA/Dogtag - Slow host deletion due to certificate pagination

[Freeipa-users] Re: Web UI login/certificate issues, IPA 4.5.4

[Freeipa-users] Re: Moving IPA master to a new server fails to start krb5kdc

[Freeipa-users] Re: Single Sign On (SSO) SSH via IP Address

[Freeipa-users] Re: Vault feature for AD users

[Freeipa-users] Re: Limits exceeded for this query

[Freeipa-users] Re: Limits exceeded for this query

[Freeipa-users] Re: Limits exceeded for this query

[Freeipa-users] Web UI login/certificate issues, IPA 4.5.4

[Freeipa-users] Re: FreeIPA/Dogtag - Slow host deletion due to certificate pagination

[Freeipa-users] Re: Limits exceeded for this query

[Freeipa-users] Re: Single Sign On (SSO) SSH via IP Address

[Freeipa-users] FreeIPA/Dogtag - Slow host deletion due to certificate pagination

[Freeipa-users] Re: new replica does not post properly in ipa_check_consistency

[Freeipa-users] Re: Vault feature for AD users

[Freeipa-users] Re: Limits exceeded for this query

[Freeipa-users] Re: Moving IPA master to a new server fails to start krb5kdc

[Freeipa-users] Re: Limits exceeded for this query

[Freeipa-users] Re: Limits exceeded for this query

[Freeipa-users] Re: Limits exceeded for this query

[Freeipa-users] Re: new replica does not post properly in ipa_check_consistency

27 matches

Site Navigation

Mail list logo

Footer information