[Freeipa-users] unindexed searches?

[Janelle]

Hello,

I hope this is a simply question. I have 1000's of these on my servers 
and it severely bogs them down. Any ideas on how to get rid of unindexed 
searches?


[04/Oct/2015:13:27:54 -0700] conn=1344502 op=11158 RESULT err=0 tag=101 
nentries=0 etime=0 notes=U
[04/Oct/2015:13:27:54 -0700] conn=1344502 op=11160 RESULT err=0 tag=101 
nentries=0 etime=0 notes=U
[04/Oct/2015:13:27:54 -0700] conn=1344502 op=11163 RESULT err=0 tag=101 
nentries=0 etime=0 notes=U
[04/Oct/2015:13:27:54 -0700] conn=1344502 op=11166 RESULT err=0 tag=101 
nentries=0 etime=0 notes=U
[04/Oct/2015:13:27:54 -0700] conn=1344502 op=11168 RESULT err=0 tag=101 
nentries=0 etime=0 notes=U
[04/Oct/2015:13:27:54 -0700] conn=1344502 op=11171 RESULT err=0 tag=101 
nentries=0 etime=0 notes=U


~Janelle

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] unindexed searches?

[Rob Crittenden]

Janelle wrote:
> Hello,
> 
> I hope this is a simply question. I have 1000's of these on my servers
> and it severely bogs them down. Any ideas on how to get rid of unindexed
> searches?
> 
> [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11158 RESULT err=0 tag=101
> nentries=0 etime=0 notes=U
> [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11160 RESULT err=0 tag=101
> nentries=0 etime=0 notes=U
> [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11163 RESULT err=0 tag=101
> nentries=0 etime=0 notes=U
> [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11166 RESULT err=0 tag=101
> nentries=0 etime=0 notes=U
> [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11168 RESULT err=0 tag=101
> nentries=0 etime=0 notes=U
> [04/Oct/2015:13:27:54 -0700] conn=1344502 op=11171 RESULT err=0 tag=101
> nentries=0 etime=0 notes=U
> 
> ~Janelle
> 

logconv from 389-ds will give you details on what those searches are.

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Cant setup replica (freeipa 4.1.3), problem with pki

[Łukasz Jaworski]

Hi,

I have problem with setup new replicas.
I tried setup two replicas, both failed with the same error.

environment:
Fedora 21

packages:
freeipa-server-4.1.3-2.fc21.x86_64
389-ds-base-1.3.3.8-1.fc21.x86_64
389-ds-base-libs-1.3.3.8-1.fc21.x86_64
pki-server-10.2.0-5.fc21.noarch

same on server and replicas


Output from ipa-replica-install:
(…)
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 
seconds
  [1/22]: creating certificate server user  
  [2/22]: configuring certificate server instance
  [3/22]: stopping certificate server instance to update CS.cfg
  [4/22]: backing up CS.cfg
  [5/22]: disabling nonces
  [6/22]: set up CRL publishing
  [7/22]: enable PKIX certificate path discovery and validation
  [8/22]: starting certificate server instance
  [error] RuntimeError: CA did not start in 300.0s

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

>From /var/log/ipareplica.log
2015-10-07T06:25:58Z DEBUG The CA status is: check interrupted
2015-10-07T06:25:58Z DEBUG Waiting for CA to start...
2015-10-07T06:25:59Z DEBUG Starting external process
2015-10-07T06:25:59Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' 
'--no-check-certificate' 'https://182.example.com:8443/ca/admin/c
a/getStatus'
2015-10-07T06:25:59Z DEBUG Process finished, return code=8
2015-10-07T06:25:59Z DEBUG stdout=
2015-10-07T06:25:59Z DEBUG stderr=--2015-10-07 08:25:59--  
https://182.example.com:8443/ca/admin/ca/getStatus
Resolving 182.example.com (182.example.com)... xx.xx.xx.xx
Connecting to 182.example.com (182.example.com)|xx.xx.xx.xx|:8443... connected.
WARNING: cannot verify 182.example.com's certificate, issued by ‘CN=Certificate 
Authority,O=ecample.com’:
  Self-signed certificate encountered.
HTTP request sent, awaiting response... 
  HTTP/1.1 500 Internal Server Error
  Server: Apache-Coyote/1.1
  Content-Type: text/html;charset=utf-8
  Content-Language: en
  Content-Length: 2923
  Date: Wed, 07 Oct 2015 06:25:59 GMT
  Connection: close
2015-10-07 08:25:59 ERROR 500: Internal Server Error.

Any idea?

Best regards,
Ender

-- 
Łukasz Jaworski


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ssh and sudo password authentication not working with freeipa-client 3.3.4-0ubuntu3.1 on Ubuntu 14.04

[Sumit Bose]

On Tue, Oct 06, 2015 at 03:39:43PM +0200, Alexander Skwar wrote:
> Hello Sumit
> 
> ipa-client-install hasn't set krb5_realm. I did that.
> 
> We're using Chef-Solo to manage our systems and I have /etc/sssd/sssd.conf
> in chef. So it overwrote, whatever ipa-client-install put there. And that's
> how the mistake happened.

Thank you for the details, I was afraid there might be an issue with
ipa-client-install. Btw, please note that there are important
differences in /etc/sssd/sssd.conf for IPA clients and servers.
Additionally if you have multiple IPA servers you should make sure that
suitable server names are used in

 ipa_server = _srv_, ipa-server.ipa.domain

on IPA clients. Although it is only a fallback server name it would
be good to have all IPA servers involved here so that in the case of
issues not all clients will fall back to the same server.

bye,
Sumit
> 
> I think the ipa-client-install discovered everything right. I'm attaching
> the log.

yes, all looks good.

> 
> Best regards,
> Alexander
> 
> 
> 
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10

[Martin Basti]

On 10/07/2015 09:49 AM, Alex Williams wrote:

Hi guys,

yesterday I finally managed to get our IPA3.0.0 servers in a state 
that I could upgrade the schema to dogtag 10, using the migration 
script and launched a new RHEL7.1 IPA4.1 server as a replica. 
Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old 
RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be our 
CRL master), I can no longer search for hosts or DNS entries, or host 
groups, either in the UI, or on the command line.


They're there, they show up when you go to the hosts, dns or user page 
in a list, but you cannot then refine the search. This is also true of 
ipa host-find and ipa hostgroup-find on the command line. Is this a 
bug in IPA4.1? Is it a schema issue? Is it just because we still have 
an IPA3 server running the show and an IPA4 replica? I can't really 
justify dropping our production IPA3 servers, if searching for records 
doesn't work in IPA4.1.


I still appear to be able to search in the UI of one of our other IPA3 
servers, despite the fact it has had its schema updated and it has 
been connected to the new IPA4 server.


Thanks in advance for any help anyone can offer.

Cheers

Alex


Hello,

can you provide more info please:

* are you kinited as admin user?
* does ipa dnszone-find returns all results?
* does ipa dnszone-find  return something?
* does ipa dnszone-show  return the zone?

We had issue with access control, where non admin users cannot search 
for zones, I'm not sure about hosts, and host groups.

I do not think that this is a schema upgrade issue nor related to Dogtag 10.

Martin

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] RedHat IdM Active Directory Integration

[Sumit Bose]

On Tue, Oct 06, 2015 at 01:48:21PM -0500, Lesley Kimmel wrote:
> Hi all;
> 
> I'm working an initiative to centralize user accounts in Active Directory.
> We have a large RHEL (6+) footprint and want to manage these as well. I am
> a Red Hat Engineer on the project and, while it is possible to integrate
> all of the RHEL clients directly to AD, I have a nagging feeling that using
> IdM as an intermediary would be a good approach. However, I have never
> implemented it and experienced the solidity of integration with AD so I
> can't formulate a solid argument at this point.
> 
> My primary belief is that using IdM would allow for the Unix administrators
> better control over their environment. However, even in that case we also
> have Satellite so we likely wouldn't use IdM for policy centralization. I'm
> curious whether it is possible to store all user, group and system objects
> in Active Directory and then allow the configuration of host based access
> control policies from IdM using those AD objects. That might be one

Does https://www.youtube.com/watch?v=sQnNFJOzwa8 help you for a start?
You can find additional details about HBAC on the IdM documentation at
https://access.redhat.com/articles/1586893 .

> argument for it. As an add-on to that question how is the HBAC actually
> implemented in IdM? It doesn't simply push down a policy for pam_access
> does it?

no, SSSD on the clients read and evaluate the HBAC rules and grants or
denies access accordingly.

> 
> Also, if users were configured with Smart Card information in AD could
> these users authenticate to Linux clients with IdM as an intermediary?

Initial Smart Card support will be available in RHEL-7.2, but only for
local authentication. In the next releases we will improve this. But is
it open to what extend those features will be made available in RHEL6.

Btw, authentication will always go directly to the right server, AD in
your case, and not use IdM as a man-in-the-middle (only in special cases
where legacy clients are involved). 

HTH

bye,
Sumit

> 
> Thanks ahead of time!
> 
> -LK

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SUDO does not always works on first try

[Jakub Hrozek]

On Mon, Oct 05, 2015 at 01:25:09PM +, Zoske, Fabian wrote:
> Dear Jakub,
> 
> I found only the following entries in the /var/log/auth.log:
> 
> Oct  5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): conversation failed
> Oct  5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): auth could not identify 
> password for [f.zo...@de.eu.local]
> Oct  5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): authentication failure; 
> logname=f.zo...@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 
> ruser=f.zo...@de.eu.local rhost= user=f.zo...@de.eu.local
> Oct  5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): received for user 
> f.zo...@de.eu.local: 7 (Authentication failure)
> Oct  5 11:57:38 hl-srv10 sudo: f.zo...@de.eu.local : user NOT authorized on 
> host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; 
> COMMAND=/bin/cat /etc/sssd/sssd.conf
> Oct  5 11:57:42 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; 
> logname=f.zo...@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 
> ruser=f.zo...@de.eu.local rhost=  user=f.zo...@de.eu.local
> Oct  5 11:57:42 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; 
> logname=f.zo...@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 
> ruser=f.zo...@de.eu.local rhost= user=f.zo...@de.eu.local
> Oct  5 11:57:43 hl-srv10 sudo: f.zo...@de.eu.local : user NOT authorized on 
> host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; 
> COMMAND=/bin/bash
> Oct  5 11:57:46 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; 
> logname=f.zo...@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 
> ruser=f.zo...@de.eu.local rhost=  user=f.zo...@de.eu.local
> Oct  5 11:57:47 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; 
> logname=f.zo...@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 
> ruser=f.zo...@de.eu.local rhost= user=f.zo...@de.eu.local
> Oct  5 11:57:47 hl-srv10 sudo: f.zo...@de.eu.local : TTY=pts/1 ; 
> PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash
> Oct  5 11:57:47 hl-srv10 sudo: pam_unix(sudo:session): session opened for 
> user root by f.zo...@de.eu.local(uid=0)
> 
> In /var/log/sssd/ no entries were logged.

Nothing gets logged in by default, you need to increase debug_level,
see:
https://fedorahosted.org/sssd/wiki/Troubleshooting

I would look into the domain log and krb5_child.log first

> 
> My sssd.conf:
> [domain/ipa-lx.com]
> 
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = ipa-lx.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = hl-srv10.ipa-lx.com
> chpass_provider = ipa
> ipa_server = _srv_, dc01.ipa-lx.com
> ldap_tls_cacert = /etc/ipa/ca.crt
> ldap_sudo_use_host_filter = false
> 
> [sssd]
> services = nss, pam, ssh, sudo
> config_file_version = 2
> default_domain_suffix = de.eu.local
> domains = ei-ag.it
> 
> [nss]
> override_shell = /bin/bash
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> 
> Best regards,
> Fabian

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10

[Alex Williams]

Hi guys,

yesterday I finally managed to get our IPA3.0.0 servers in a state that 
I could upgrade the schema to dogtag 10, using the migration script and 
launched a new RHEL7.1 IPA4.1 server as a replica. Unfortunately, in 
both the new RHEL7.1 IPA4.1 server AND the old RHEL6.6 IPA3.0.0 server 
that I replicated from (Also happens to be our CRL master), I can no 
longer search for hosts or DNS entries, or host groups, either in the 
UI, or on the command line.


They're there, they show up when you go to the hosts, dns or user page 
in a list, but you cannot then refine the search. This is also true of 
ipa host-find and ipa hostgroup-find on the command line. Is this a bug 
in IPA4.1? Is it a schema issue? Is it just because we still have an 
IPA3 server running the show and an IPA4 replica? I can't really justify 
dropping our production IPA3 servers, if searching for records doesn't 
work in IPA4.1.


I still appear to be able to search in the UI of one of our other IPA3 
servers, despite the fact it has had its schema updated and it has been 
connected to the new IPA4 server.


Thanks in advance for any help anyone can offer.

Cheers

Alex

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo rules do not seem to work

[Jakub Hrozek]

On Tue, Oct 06, 2015 at 06:28:14PM +0200, Karl Forner wrote:
> Hello,
> 
> I had assumed sudo rules worked because I have an "allow_all for admins"
> sudo rule that seemed to work, but I wonder if there is an implicit rule
> for the special group admins ?
> 
> 
> Because I have tried to replicate this allow_all rule for for other user
> groups, and it does not seem to work at all.
> What's strange is that "sudo -l"  report the appropriate rules, but they do
> not work.
> 
> For instance, some users have: (ALL) ALL listed with sudo -l, but they can
> not use sudo.
> 
> My user has:
> (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status
> (ALL) ALL
> (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *, /bin/chmod
> -R g[+-]* *
> (ALL) NOPASSWD: /usr/bin/less
> (ALL) ALL
> 
> but I'm prompted a password when doing "sudo /usr/bin/less".
> 
> How can I debug this ?

Pavel (CC) has a nice sudo debug howto, maybe it would be helpful?

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Web login problems

[Simo Sorce]

On 07/10/15 13:36, Pat Gunn wrote:

Hi,
I'm trying to build a cluster of 3 IPA (staging at this point, but
eventually later I'll make a prod version)
systems (that will reside in AWS) that will manage select systems in our
infrastructure (mostly but not entirely in AWS).
The systems will be fronted (like most of our infrastructure) with a
load-balancer that manages pooling and SSL termination; we'd like
freeipa-staging.corp.$ORGNAME.com to be the access point, and the LB will
then route that to a specific one of the three servers based on pool
settings).


Please read this before you proceed with your LB plan:
http://ssimo.org/blog/id_019.html

HTH,
Simo.



The systems are running CentOS7 and have the RPM-bundled version of FreeIPA
(4.1.0). Our three IPA servers are named
freeipa-staging-[123].vpc3.$INTERNALNAME.cc - the servers that will be
managed by this will have a variety of names and locations (and
$INTERNALNAME differs from $ORGNAME but both are valid DNSnames)

After running ipa-server-install on the first box (no integrated DNS
enabled, realmname is IPA-STAGING.$ORGNAME.ORG), I modified the
ipa-rewrite.conf to trim it down to this:
RewriteEngine on
RewriteRule ^/$ /ipa/ui [L,NC,R=301]
RewriteRule ^/ipa/ui/js/freeipa/plugins.js$/ipa/wsgi/plugins.py [PT]


After the stack starts, I can kinit and run commands. Everything looks
good. The WebUI isn't working for me though - when I enter admin and the
password, I get "Your session has expired. Please re-login". By contrast,
when I give the wrong password, it tells me it's wrong.

After enabling debugging in ipa.conf, this is what I get from the httpd
error log:

[Wed Oct 07 17:29:50.370982 2015] [:error] [pid 3000] ipa: DEBUG: WSGI
wsgi_dispatch.__call__:
[Wed Oct 07 17:29:50.371088 2015] [:error] [pid 3000] ipa: DEBUG: WSGI
login_password.__call__:
[Wed Oct 07 17:29:50.371438 2015] [:error] [pid 3000] ipa: DEBUG: Obtaining
armor ccache: principal=HTTP/
freeipa-staging-1.vpc3.internalname...@ipa-staging.orgname.org
keytab=/etc/httpd/conf/ipa.keytab
ccache=/var/run/ipa_memcached/krbcc_A_admin
[Wed Oct 07 17:29:50.371534 2015] [:error] [pid 3000] ipa: DEBUG: Starting
external process
[Wed Oct 07 17:29:50.371596 2015] [:error] [pid 3000] ipa: DEBUG:
args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' 'HTTP/
freeipa-staging-1.vpc3.internalname...@ipa-staging.orgname.org'
[Wed Oct 07 17:29:50.415134 2015] [:error] [pid 3000] ipa: DEBUG: Process
finished, return code=0
[Wed Oct 07 17:29:50.415223 2015] [:error] [pid 3000] ipa: DEBUG: stdout=
[Wed Oct 07 17:29:50.415276 2015] [:error] [pid 3000] ipa: DEBUG: stderr=
[Wed Oct 07 17:29:50.415395 2015] [:error] [pid 3000] ipa: DEBUG: Starting
external process
[Wed Oct 07 17:29:50.415458 2015] [:error] [pid 3000] ipa: DEBUG:
args='/usr/bin/kinit' 'ad...@ipa-staging.orgname.org' '-T'
'/var/run/ipa_memcached/krbcc_A_admin'
[Wed Oct 07 17:29:50.486981 2015] [:error] [pid 3000] ipa: DEBUG: Process
finished, return code=0
[Wed Oct 07 17:29:50.487072 2015] [:error] [pid 3000] ipa: DEBUG:
stdout=Password for ad...@ipa-staging.orgname.org:
[Wed Oct 07 17:29:50.487079 2015] [:error] [pid 3000]
[Wed Oct 07 17:29:50.487129 2015] [:error] [pid 3000] ipa: DEBUG: stderr=
[Wed Oct 07 17:29:50.487228 2015] [:error] [pid 3000] ipa: DEBUG: kinit:
principal=ad...@ipa-staging.orgname.org returncode=0, stderr=""
[Wed Oct 07 17:29:50.487281 2015] [:error] [pid 3000] ipa: DEBUG: Cleanup
the armor ccache
[Wed Oct 07 17:29:50.487356 2015] [:error] [pid 3000] ipa: DEBUG: Starting
external process
[Wed Oct 07 17:29:50.487406 2015] [:error] [pid 3000] ipa: DEBUG:
args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin'
[Wed Oct 07 17:29:50.500419 2015] [:error] [pid 3000] ipa: DEBUG: Process
finished, return code=0
[Wed Oct 07 17:29:50.500496 2015] [:error] [pid 3000] ipa: DEBUG: stdout=
[Wed Oct 07 17:29:50.500547 2015] [:error] [pid 3000] ipa: DEBUG: stderr=
[Wed Oct 07 17:29:50.501180 2015] [:error] [pid 3000] ipa: DEBUG: no
session cookie found
[Wed Oct 07 17:29:50.501501 2015] [:error] [pid 3000] ipa: DEBUG: no
session id in request, generating empty session data with
id=738fef28e7a985fe8f01e0fc2a1c8e7d
[Wed Oct 07 17:29:50.501607 2015] [:error] [pid 3000] ipa: DEBUG: store
session: session_id=738fef28e7a985fe8f01e0fc2a1c8e7d
start_timestamp=2015-10-07T17:29:50 access_timestamp=2015-10-07T17:29:50
expiration_timestamp=1970-01-01T00:00:00
[Wed Oct 07 17:29:50.501908 2015] [:error] [pid 3000] ipa: DEBUG:
finalize_kerberos_acquisition: login_password
ccache_name="FILE:/var/run/ipa_memcached/krbcc_3000"
session_id="738fef28e7a985fe8f01e0fc2a1c8e7d"
[Wed Oct 07 17:29:50.501978 2015] [:error] [pid 3000] ipa: DEBUG: reading
ccache data from file "/var/run/ipa_memcached/krbcc_3000"
[Wed Oct 07 17:29:50.502358 2015] [:error] [pid 3000] ipa: DEBUG:
get_credential_times: principal=krbtgt/
ipa-staging.orgname@ipa-staging.orgname.org, authtime=10/07/15
17:29:50, starttime=10/07/15 17:29:50, endtime=10/08/15 17:29:50,

Re: [Freeipa-users] RedHat IdM Active Directory Integration

[Martin Kosek]

On 10/06/2015 07:35 PM, Lesley Kimmel wrote:
> Hi all;
> 
> I'm working an initiative to centralize user accounts in Active Directory.
> We have a large RHEL (6+) footprint and want to manage these as well. I am
> a Red Hat Engineer on the project and, while it is possible to integrate
> all of the RHEL clients directly to AD, I have a nagging feeling that using
> IdM as an intermediary would be a good approach. However, I have never
> implemented it and experienced the solidity of integration with AD so I
> can't formulate a solid argument at this point.
> 
> My primary belief is that using IdM would allow for the Unix administrators
> better control over their environment.

Yes, it would allow you easy control/integration for Linux based services, like
SUDO, automount and others. It may also save some costs, as if you join the
hosts directly to AD, you may need to pay the CLAs.

> However, even in that case we also
> have Satellite so we likely wouldn't use IdM for policy centralization.

What policy do you have in mind right now, authorization?

> I'm
> curious whether it is possible to store all user, group and system objects
> in Active Directory and then allow the configuration of host based access
> control policies from IdM using those AD objects.

Yes, this should work with IdM external groups used in HBAC:
https://www.youtube.com/watch?v=sQnNFJOzwa8

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/configuring-host-access.html#about-hbac

> That might be one
> argument for it. As an add-on to that question how is the HBAC actually
> implemented in IdM? It doesn't simply push down a policy for pam_access
> does it?

HBAC is evaluated on the client (SSSD), i.e. that makes SSSD a requirement to
use HBAC.

> 
> Also, if users were configured with Smart Card information in AD could
> these users authenticate to Linux clients with IdM as an intermediary?

This *may* work with the current Smart Card implementation in SSSD 1.13. It
should just work with IdM users and registered SC certificates out of the box,
for AD, some additional configuration will be required, Sumit will know more.

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo rules do not seem to work

[Jakub Hrozek]

On Wed, Oct 07, 2015 at 11:19:02AM +0200, Pavel Březina wrote:
> On 10/07/2015 10:03 AM, Jakub Hrozek wrote:
> >On Tue, Oct 06, 2015 at 06:28:14PM +0200, Karl Forner wrote:
> >>Hello,
> >>
> >>I had assumed sudo rules worked because I have an "allow_all for admins"
> >>sudo rule that seemed to work, but I wonder if there is an implicit rule
> >>for the special group admins ?
> >>
> >>
> >>Because I have tried to replicate this allow_all rule for for other user
> >>groups, and it does not seem to work at all.
> >>What's strange is that "sudo -l"  report the appropriate rules, but they do
> >>not work.
> >>
> >>For instance, some users have: (ALL) ALL listed with sudo -l, but they can
> >>not use sudo.
> >>
> >>My user has:
> >> (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status
> >> (ALL) ALL
> >> (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *, /bin/chmod
> >>-R g[+-]* *
> >> (ALL) NOPASSWD: /usr/bin/less
> >> (ALL) ALL
> >>
> >>but I'm prompted a password when doing "sudo /usr/bin/less".
> >>
> >>How can I debug this ?
> >
> >Pavel (CC) has a nice sudo debug howto, maybe it would be helpful?
> 
> Hi,
> you are prompted for password because (ALL) ALL rule is applied because of
> last-match rule. See: http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html
> sudoOrder.

This might be a nice addition to your howto :)

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10

[Martin Basti]

On 10/07/2015 12:28 PM, Martin Basti wrote:



On 10/07/2015 12:10 PM, Alex Williams wrote:

On 07/10/15 10:57, Martin Basti wrote:



On 10/07/2015 11:23 AM, Alex Williams wrote:

On 07/10/15 09:53, Martin Basti wrote:



On 10/07/2015 09:49 AM, Alex Williams wrote:

Hi guys,

yesterday I finally managed to get our IPA3.0.0 servers in a 
state that I could upgrade the schema to dogtag 10, using the 
migration script and launched a new RHEL7.1 IPA4.1 server as a 
replica. Unfortunately, in both the new RHEL7.1 IPA4.1 server AND 
the old RHEL6.6 IPA3.0.0 server that I replicated from (Also 
happens to be our CRL master), I can no longer search for hosts 
or DNS entries, or host groups, either in the UI, or on the 
command line.


They're there, they show up when you go to the hosts, dns or user 
page in a list, but you cannot then refine the search. This is 
also true of ipa host-find and ipa hostgroup-find on the command 
line. Is this a bug in IPA4.1? Is it a schema issue? Is it just 
because we still have an IPA3 server running the show and an IPA4 
replica? I can't really justify dropping our production IPA3 
servers, if searching for records doesn't work in IPA4.1.


I still appear to be able to search in the UI of one of our other 
IPA3 servers, despite the fact it has had its schema updated and 
it has been connected to the new IPA4 server.


Thanks in advance for any help anyone can offer.

Cheers

Alex


Hello,

can you provide more info please:

* are you kinited as admin user?
* does ipa dnszone-find returns all results?
* does ipa dnszone-find  return something?
* does ipa dnszone-show  return the zone?

We had issue with access control, where non admin users cannot 
search for zones, I'm not sure about hosts, and host groups.
I do not think that this is a schema upgrade issue nor related to 
Dogtag 10.


Martin


Hi Martin,

thanks for the quick response. So, I have not kinited as the admin 
user, however as root and as my own username (A member of the 
admins group in IPA), all of the commands you requested that I 
test, work fine. As it turns out, I can run all of the following on 
the command line, as my user, or as root and it all works fine. My 
colleague who attempted to do so this morning under his username, 
can do so if he kinits to admin. So I'm assuming the CLI bit, might 
be an ACL issue? Unfortunately, my user still cannot search for 
hosts, hostgroups, or DNS entries within the UI.


ipa user-find - returns a list of 100 users
ipa user-find $username - returns the details of that user
ipa host-find returns a list of 100 hosts
ipa host-find $hostname - returns the details of the host
ipa host-find $partial-hostname - returns a list of hosts which 
have the search string inside their hostname

ipa hostgroup-find - returns a list of hostgroups
ipa hostgroup-find $hostgroupname - returns details of the hostgroup

Regards

Alex


If I understand correctly, you as admin group user, can search in 
CLI and cannot search in webUI? That is weird.


For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS 
disallow some queries from user that are not in admin group.


Martin


Hi Martin,

yes, that's exactly right, we seem to be able to search in the CLI, 
provided we're in the admin group, or kinit to the admin user. For 
some reason though, searching in the UI brings back nothing at all. 
It works ok for users, but not for hosts, hostgroups, or DNS entries. 
All of the entries are there, they are listed in full when you visit 
the respective page, but even searching for a full hostname doesn't 
work, let alone part of it. CLI is always an option obviously, but we 
don't really want everyone who uses this to have to use the CLI, just 
to search for a hostname or DNS entry.
Please login in webUI as admin and try search, in this case search 
should work, if not, there is something broken.


I found related tickets:
https://fedorahosted.org/freeipa/ticket/5055
https://fedorahosted.org/freeipa/ticket/5130

But I found nothing about hosts and hostsgroup, I will prepare test 
environment and try.
Nevermind, here is hosts/hostgroup/service/netgroup ticket 
https://fedorahosted.org/freeipa/ticket/5167


I've also verified that replication of things like hosts and DNS 
entries is working perfectly well between the IPA4 and IPA3 servers. 
If I add a new DNS entry in IPA3, it shows up immediately in IPA4 and 
I can then delete it in IPA4 and it's removed instantly from the IPA3 
server.


Cheers

Alex





--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] DNS forwarding configuration randomly breaks and stops working

[Petr Spacek]

On 6.10.2015 18:57, nat...@nathanpeters.com wrote:
>> Your expectation #1 is correct, but there can be multiple reasons why it
>> fails.
>>
>> Did you try to set forward policy = only as I advised you in the previous
>> e-mail? Forward policy 'first' does not make sense when split-DNS is
>> involved
>> because you can end up with mixture of records from different views in one
>> cache, which obviously results in a mess.
> 
> Yes, we ended up having to use the forward only policy to get this
> working.  That is unfortunate, because if our forwarding server ever goes
> down or gets rebooted, that essentially disconnects us from being able to
> resolve external internet domain names.  It would be nice to have
> recursion as a fallback, but it seems to go into that mode too often to be
> useful in our split DNS situation.
> 
>>> 2. We did some more network packet capture, and noticed that in forward
>>> first mode, the FreeIPA server, always sent out both a forward request
>>> to
>>> the forwarding server, and an additional simultaneous request to the
>>> root
>>> name servers (recursive mode).  It got back responses to both the
>>> forwarded and recursive queries it had performed.  The recursive query
>>> failed due to split DNS and the forwarded query succeeded due to it
>>> going
>>> to an internal server which had the correct records.  Strangely
>>> enough...
>>> the IPA server ignored the successful forwarded answer, and sent back
>>> the
>>> 'failed' answer it had gotten through recursion back to the requesting
>>> client.  What is the behavior supposed to be in this situation and why
>>> is
>>> the server always sending out the recursive request, even when it gets a
>>> valid answer from the forwarded request?
>>
>> This is weird, but again - it can have multiple reasons. Do you see
>> something
>> in BIND logs? Does it e.g. complain about DNSSEC validation failures?
>>
>> Petr^2 Spacek
>>
> 
> Yes, we actually were getting DNSSEC validation failures. We had to
> disable DNSSEC to get the forward only policy to work.  With DNSSEC turned
> on, forward only would not work because DNSSEC still tried to directly
> contact root servers.

It is very likely that this was caused by some misconfiguration in your DNS
views. Could you share error messages from BIND logs? We could use them to
improve detection logic so we can warn users early instead of tedious debugging.

BTW what version if IPA do you use? We were adding checks to catch common
misconfigurations to version 4.2.

-- 
Petr Spacek  @  Red Hat

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10

[Alex Williams]

On 07/10/15 10:57, Martin Basti wrote:



On 10/07/2015 11:23 AM, Alex Williams wrote:

On 07/10/15 09:53, Martin Basti wrote:



On 10/07/2015 09:49 AM, Alex Williams wrote:

Hi guys,

yesterday I finally managed to get our IPA3.0.0 servers in a state 
that I could upgrade the schema to dogtag 10, using the migration 
script and launched a new RHEL7.1 IPA4.1 server as a replica. 
Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old 
RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be 
our CRL master), I can no longer search for hosts or DNS entries, 
or host groups, either in the UI, or on the command line.


They're there, they show up when you go to the hosts, dns or user 
page in a list, but you cannot then refine the search. This is also 
true of ipa host-find and ipa hostgroup-find on the command line. 
Is this a bug in IPA4.1? Is it a schema issue? Is it just because 
we still have an IPA3 server running the show and an IPA4 replica? 
I can't really justify dropping our production IPA3 servers, if 
searching for records doesn't work in IPA4.1.


I still appear to be able to search in the UI of one of our other 
IPA3 servers, despite the fact it has had its schema updated and it 
has been connected to the new IPA4 server.


Thanks in advance for any help anyone can offer.

Cheers

Alex


Hello,

can you provide more info please:

* are you kinited as admin user?
* does ipa dnszone-find returns all results?
* does ipa dnszone-find  return something?
* does ipa dnszone-show  return the zone?

We had issue with access control, where non admin users cannot 
search for zones, I'm not sure about hosts, and host groups.
I do not think that this is a schema upgrade issue nor related to 
Dogtag 10.


Martin


Hi Martin,

thanks for the quick response. So, I have not kinited as the admin 
user, however as root and as my own username (A member of the admins 
group in IPA), all of the commands you requested that I test, work 
fine. As it turns out, I can run all of the following on the command 
line, as my user, or as root and it all works fine. My colleague who 
attempted to do so this morning under his username, can do so if he 
kinits to admin. So I'm assuming the CLI bit, might be an ACL issue? 
Unfortunately, my user still cannot search for hosts, hostgroups, or 
DNS entries within the UI.


ipa user-find - returns a list of 100 users
ipa user-find $username - returns the details of that user
ipa host-find returns a list of 100 hosts
ipa host-find $hostname - returns the details of the host
ipa host-find $partial-hostname - returns a list of hosts which have 
the search string inside their hostname

ipa hostgroup-find - returns a list of hostgroups
ipa hostgroup-find $hostgroupname - returns details of the hostgroup

Regards

Alex


If I understand correctly, you as admin group user, can search in CLI 
and cannot search in webUI? That is weird.


For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS 
disallow some queries from user that are not in admin group.


Martin


Hi Martin,

yes, that's exactly right, we seem to be able to search in the CLI, 
provided we're in the admin group, or kinit to the admin user. For some 
reason though, searching in the UI brings back nothing at all. It works 
ok for users, but not for hosts, hostgroups, or DNS entries. All of the 
entries are there, they are listed in full when you visit the respective 
page, but even searching for a full hostname doesn't work, let alone 
part of it. CLI is always an option obviously, but we don't really want 
everyone who uses this to have to use the CLI, just to search for a 
hostname or DNS entry.


I've also verified that replication of things like hosts and DNS entries 
is working perfectly well between the IPA4 and IPA3 servers. If I add a 
new DNS entry in IPA3, it shows up immediately in IPA4 and I can then 
delete it in IPA4 and it's removed instantly from the IPA3 server.


Cheers

Alex

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] RedHat IdM Active Directory Integration

[Martin Kosek]

On 10/07/2015 12:01 PM, Martin Kosek wrote:
> On 10/06/2015 07:35 PM, Lesley Kimmel wrote:
>> Hi all;
>>
>> I'm working an initiative to centralize user accounts in Active Directory.
>> We have a large RHEL (6+) footprint and want to manage these as well. I am
>> a Red Hat Engineer on the project and, while it is possible to integrate
>> all of the RHEL clients directly to AD, I have a nagging feeling that using
>> IdM as an intermediary would be a good approach. However, I have never
>> implemented it and experienced the solidity of integration with AD so I
>> can't formulate a solid argument at this point.
>>
>> My primary belief is that using IdM would allow for the Unix administrators
>> better control over their environment.
> 
> Yes, it would allow you easy control/integration for Linux based services, 
> like
> SUDO, automount and others. It may also save some costs, as if you join the
> hosts directly to AD, you may need to pay the CLAs.

BTW, Dmitri Pal also published a set of great blogs about IdM that can help you
too:

http://rhelblog.redhat.com/2015/05/27/direct-or-indirect-that-is-the-question/

... aaand a related presentation:
https://drive.google.com/file/d/0B3tfpNCVjJdCU1d3c0gzTE9pU2c/view?usp=sharing

> 
>> However, even in that case we also
>> have Satellite so we likely wouldn't use IdM for policy centralization.
> 
> What policy do you have in mind right now, authorization?
> 
>> I'm
>> curious whether it is possible to store all user, group and system objects
>> in Active Directory and then allow the configuration of host based access
>> control policies from IdM using those AD objects.
> 
> Yes, this should work with IdM external groups used in HBAC:
> https://www.youtube.com/watch?v=sQnNFJOzwa8
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/configuring-host-access.html#about-hbac
> 
>> That might be one
>> argument for it. As an add-on to that question how is the HBAC actually
>> implemented in IdM? It doesn't simply push down a policy for pam_access
>> does it?
> 
> HBAC is evaluated on the client (SSSD), i.e. that makes SSSD a requirement to
> use HBAC.
> 
>>
>> Also, if users were configured with Smart Card information in AD could
>> these users authenticate to Linux clients with IdM as an intermediary?
> 
> This *may* work with the current Smart Card implementation in SSSD 1.13. It
> should just work with IdM users and registered SC certificates out of the box,
> for AD, some additional configuration will be required, Sumit will know more.
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10

[Martin Basti]

On 10/07/2015 01:26 PM, Alex Williams wrote:

On 07/10/15 11:31, Martin Basti wrote:



On 10/07/2015 12:28 PM, Martin Basti wrote:



On 10/07/2015 12:10 PM, Alex Williams wrote:

On 07/10/15 10:57, Martin Basti wrote:



On 10/07/2015 11:23 AM, Alex Williams wrote:

On 07/10/15 09:53, Martin Basti wrote:



On 10/07/2015 09:49 AM, Alex Williams wrote:

Hi guys,

yesterday I finally managed to get our IPA3.0.0 servers in a 
state that I could upgrade the schema to dogtag 10, using the 
migration script and launched a new RHEL7.1 IPA4.1 server as a 
replica. Unfortunately, in both the new RHEL7.1 IPA4.1 server 
AND the old RHEL6.6 IPA3.0.0 server that I replicated from 
(Also happens to be our CRL master), I can no longer search for 
hosts or DNS entries, or host groups, either in the UI, or on 
the command line.


They're there, they show up when you go to the hosts, dns or 
user page in a list, but you cannot then refine the search. 
This is also true of ipa host-find and ipa hostgroup-find on 
the command line. Is this a bug in IPA4.1? Is it a schema 
issue? Is it just because we still have an IPA3 server running 
the show and an IPA4 replica? I can't really justify dropping 
our production IPA3 servers, if searching for records doesn't 
work in IPA4.1.


I still appear to be able to search in the UI of one of our 
other IPA3 servers, despite the fact it has had its schema 
updated and it has been connected to the new IPA4 server.


Thanks in advance for any help anyone can offer.

Cheers

Alex


Hello,

can you provide more info please:

* are you kinited as admin user?
* does ipa dnszone-find returns all results?
* does ipa dnszone-find  return something?
* does ipa dnszone-show  return the zone?

We had issue with access control, where non admin users cannot 
search for zones, I'm not sure about hosts, and host groups.
I do not think that this is a schema upgrade issue nor related 
to Dogtag 10.


Martin


Hi Martin,

thanks for the quick response. So, I have not kinited as the 
admin user, however as root and as my own username (A member of 
the admins group in IPA), all of the commands you requested that 
I test, work fine. As it turns out, I can run all of the 
following on the command line, as my user, or as root and it all 
works fine. My colleague who attempted to do so this morning 
under his username, can do so if he kinits to admin. So I'm 
assuming the CLI bit, might be an ACL issue? Unfortunately, my 
user still cannot search for hosts, hostgroups, or DNS entries 
within the UI.


ipa user-find - returns a list of 100 users
ipa user-find $username - returns the details of that user
ipa host-find returns a list of 100 hosts
ipa host-find $hostname - returns the details of the host
ipa host-find $partial-hostname - returns a list of hosts which 
have the search string inside their hostname

ipa hostgroup-find - returns a list of hostgroups
ipa hostgroup-find $hostgroupname - returns details of the hostgroup

Regards

Alex


If I understand correctly, you as admin group user, can search in 
CLI and cannot search in webUI? That is weird.


For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS 
disallow some queries from user that are not in admin group.


Martin


Hi Martin,

yes, that's exactly right, we seem to be able to search in the CLI, 
provided we're in the admin group, or kinit to the admin user. For 
some reason though, searching in the UI brings back nothing at all. 
It works ok for users, but not for hosts, hostgroups, or DNS 
entries. All of the entries are there, they are listed in full when 
you visit the respective page, but even searching for a full 
hostname doesn't work, let alone part of it. CLI is always an 
option obviously, but we don't really want everyone who uses this 
to have to use the CLI, just to search for a hostname or DNS entry.
Please login in webUI as admin and try search, in this case search 
should work, if not, there is something broken.


I found related tickets:
https://fedorahosted.org/freeipa/ticket/5055
https://fedorahosted.org/freeipa/ticket/5130

But I found nothing about hosts and hostsgroup, I will prepare test 
environment and try.
Nevermind, here is hosts/hostgroup/service/netgroup ticket 
https://fedorahosted.org/freeipa/ticket/5167


I've also verified that replication of things like hosts and DNS 
entries is working perfectly well between the IPA4 and IPA3 
servers. If I add a new DNS entry in IPA3, it shows up immediately 
in IPA4 and I can then delete it in IPA4 and it's removed instantly 
from the IPA3 server.


Cheers

Alex








Hi Martin,

thanks for that, that does in fact seem to be the issue. As per your 
instructions, logging in as 'admin' to the UI, allows the search 
feature to work. That does beg the question as to how my user can use 
its kerberos ticket on the CLI, but not in the UI though? Either way, 
the fix for the issue looks to be trivial (Replacing a few python 
files by the looks of things), so I'll 

Re: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts

[Martin Kosek]

On 10/05/2015 02:13 PM, Dominik Korittki wrote:
> 
> 
> Am 01.10.2015 um 21:52 schrieb Rob Crittenden:
>> Dominik Korittki wrote:
>>> Hello folks,
>>>
>>> I am running two FreeIPA Servers with around 100 users and around 15.000
>>> hosts, which are used by users to login via ssh. The FreeIPA servers
>>> (which are Centos 7.0) ran good for a while, but as more and more hosts
>>> got migrated to serve as FreeIPA hosts, it started to get slow and
>>> unstable.
>>>
>>> For example, its hard to maintain hostgroups, which have more than 1.000
>>> hosts. The ipa host-* commands are getting slower as the hostgroup
>>> grows. Is this normal?
>>
>> You mean the ipa hostgroup-* commands? Whenever the entry is displayed
>> (show and add) it needs to dereference all members so yes, it is
>> understandable that it gets somewhat slower with more members. How slow
>> are we talking about?
>>
>>> We also experience random dirsrv segfaults. Here's a dmesg line from the
>>> latest:
>>>
>>> [690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1
>>> sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b65+1b6000]
>>
>> You probably want to start here:
>> http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
> 
> A stacktrace from the latest crash is attached to this email. After restarting
> the service, this is what I get in /var/log/dirsrv/slapd-INTERNAL/errors
> (hostname is ipa01.internal):

Ludwig or Thierry, can you please take a look at the stack and file 389-DS
ticket if appropriate?

> 
> [05/Oct/2015:13:51:30 +0200] - slapd started.  Listening on All Interfaces 
> port
> 389 for LDAP requests
> [05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636 for LDAPS
> requests
> [05/Oct/2015:13:51:30 +0200] - Listening on /var/run/slapd-INTERNAL.socket for
> LDAPI requests
> [05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind - Error: could
> not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local
> error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. 
> Minor code may provide more information (No Kerberos credentials available))
> errno 0 (Success)
> [05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not perform
> interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local
> error)
> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -
> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI auth
> failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information (No Kerberos
> credentials available))
> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog program -
> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN
> 54bea4800060 not found, we aren't as up to date, or we purged
> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -
> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Data 
> required
> to update replica has been purged. The replica must be reinitialized.
> [05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -
> agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Incremental
> update failed and requires administrator action
> [05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin -
> agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI auth
> resumed
> 
> 
> These lines are present since a replayed a ldif dump from ipa02 to ipa01, but 
> i
> didn't think that it related to the segfault problem (therefore i said there
> are no related problems in the logfile).
> 
> But I am starting to believe that these errors could be in relation to each 
> other.
> 
> 
> Kind regards,
> Dominik Korittki
> 
> 
>>
>>
>>> Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the
>>> problem.
> 
> Not sure about that anymore.
> 
>>> I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that
>>> solve my problems?
>>>
>>> FreeIPA server version is 3.3.3-28.el7.centos
>>> 389-ds-base.x86_64 is 1.3.1.6-26.el7_0
>>>
>>>
>>>
>>> Kind regards,
>>> Dominik Korittki
>>>
>>
>>
>>
>>
> 
> 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo rules do not seem to work

[Pavel Březina]

On 10/07/2015 10:03 AM, Jakub Hrozek wrote:

On Tue, Oct 06, 2015 at 06:28:14PM +0200, Karl Forner wrote:

Hello,

I had assumed sudo rules worked because I have an "allow_all for admins"
sudo rule that seemed to work, but I wonder if there is an implicit rule
for the special group admins ?


Because I have tried to replicate this allow_all rule for for other user
groups, and it does not seem to work at all.
What's strange is that "sudo -l"  report the appropriate rules, but they do
not work.

For instance, some users have: (ALL) ALL listed with sudo -l, but they can
not use sudo.

My user has:
 (root) NOPASSWD: /usr/bin/git status, /usr/local/bin/git status
 (ALL) ALL
 (root) NOPASSWD: /bin/chgrp qbstaff *, /bin/chmod g[+-]* *, /bin/chmod
-R g[+-]* *
 (ALL) NOPASSWD: /usr/bin/less
 (ALL) ALL

but I'm prompted a password when doing "sudo /usr/bin/less".

How can I debug this ?


Pavel (CC) has a nice sudo debug howto, maybe it would be helpful?


Hi,
you are prompted for password because (ALL) ALL rule is applied because 
of last-match rule. See: 
http://www.sudo.ws/man/1.8.13/sudoers.ldap.man.html sudoOrder.



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10

[Alex Williams]

On 07/10/15 12:40, Martin Basti wrote:



On 10/07/2015 01:26 PM, Alex Williams wrote:

On 07/10/15 11:31, Martin Basti wrote:



On 10/07/2015 12:28 PM, Martin Basti wrote:



On 10/07/2015 12:10 PM, Alex Williams wrote:

On 07/10/15 10:57, Martin Basti wrote:



On 10/07/2015 11:23 AM, Alex Williams wrote:

On 07/10/15 09:53, Martin Basti wrote:



On 10/07/2015 09:49 AM, Alex Williams wrote:

Hi guys,

yesterday I finally managed to get our IPA3.0.0 servers in a 
state that I could upgrade the schema to dogtag 10, using the 
migration script and launched a new RHEL7.1 IPA4.1 server as a 
replica. Unfortunately, in both the new RHEL7.1 IPA4.1 server 
AND the old RHEL6.6 IPA3.0.0 server that I replicated from 
(Also happens to be our CRL master), I can no longer search 
for hosts or DNS entries, or host groups, either in the UI, or 
on the command line.


They're there, they show up when you go to the hosts, dns or 
user page in a list, but you cannot then refine the search. 
This is also true of ipa host-find and ipa hostgroup-find on 
the command line. Is this a bug in IPA4.1? Is it a schema 
issue? Is it just because we still have an IPA3 server running 
the show and an IPA4 replica? I can't really justify dropping 
our production IPA3 servers, if searching for records doesn't 
work in IPA4.1.


I still appear to be able to search in the UI of one of our 
other IPA3 servers, despite the fact it has had its schema 
updated and it has been connected to the new IPA4 server.


Thanks in advance for any help anyone can offer.

Cheers

Alex


Hello,

can you provide more info please:

* are you kinited as admin user?
* does ipa dnszone-find returns all results?
* does ipa dnszone-find  return something?
* does ipa dnszone-show  return the zone?

We had issue with access control, where non admin users cannot 
search for zones, I'm not sure about hosts, and host groups.
I do not think that this is a schema upgrade issue nor related 
to Dogtag 10.


Martin


Hi Martin,

thanks for the quick response. So, I have not kinited as the 
admin user, however as root and as my own username (A member of 
the admins group in IPA), all of the commands you requested that 
I test, work fine. As it turns out, I can run all of the 
following on the command line, as my user, or as root and it all 
works fine. My colleague who attempted to do so this morning 
under his username, can do so if he kinits to admin. So I'm 
assuming the CLI bit, might be an ACL issue? Unfortunately, my 
user still cannot search for hosts, hostgroups, or DNS entries 
within the UI.


ipa user-find - returns a list of 100 users
ipa user-find $username - returns the details of that user
ipa host-find returns a list of 100 hosts
ipa host-find $hostname - returns the details of the host
ipa host-find $partial-hostname - returns a list of hosts which 
have the search string inside their hostname

ipa hostgroup-find - returns a list of hostgroups
ipa hostgroup-find $hostgroupname - returns details of the 
hostgroup


Regards

Alex


If I understand correctly, you as admin group user, can search in 
CLI and cannot search in webUI? That is weird.


For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS 
disallow some queries from user that are not in admin group.


Martin


Hi Martin,

yes, that's exactly right, we seem to be able to search in the 
CLI, provided we're in the admin group, or kinit to the admin 
user. For some reason though, searching in the UI brings back 
nothing at all. It works ok for users, but not for hosts, 
hostgroups, or DNS entries. All of the entries are there, they are 
listed in full when you visit the respective page, but even 
searching for a full hostname doesn't work, let alone part of it. 
CLI is always an option obviously, but we don't really want 
everyone who uses this to have to use the CLI, just to search for 
a hostname or DNS entry.
Please login in webUI as admin and try search, in this case search 
should work, if not, there is something broken.


I found related tickets:
https://fedorahosted.org/freeipa/ticket/5055
https://fedorahosted.org/freeipa/ticket/5130

But I found nothing about hosts and hostsgroup, I will prepare test 
environment and try.
Nevermind, here is hosts/hostgroup/service/netgroup ticket 
https://fedorahosted.org/freeipa/ticket/5167


I've also verified that replication of things like hosts and DNS 
entries is working perfectly well between the IPA4 and IPA3 
servers. If I add a new DNS entry in IPA3, it shows up immediately 
in IPA4 and I can then delete it in IPA4 and it's removed 
instantly from the IPA3 server.


Cheers

Alex








Hi Martin,

thanks for that, that does in fact seem to be the issue. As per your 
instructions, logging in as 'admin' to the UI, allows the search 
feature to work. That does beg the question as to how my user can use 
its kerberos ticket on the CLI, but not in the UI though? Either way, 
the fix for the issue looks to be trivial (Replacing a few python 

Re: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10

[Martin Basti]

On 10/07/2015 11:23 AM, Alex Williams wrote:

On 07/10/15 09:53, Martin Basti wrote:



On 10/07/2015 09:49 AM, Alex Williams wrote:

Hi guys,

yesterday I finally managed to get our IPA3.0.0 servers in a state 
that I could upgrade the schema to dogtag 10, using the migration 
script and launched a new RHEL7.1 IPA4.1 server as a replica. 
Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old 
RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be 
our CRL master), I can no longer search for hosts or DNS entries, or 
host groups, either in the UI, or on the command line.


They're there, they show up when you go to the hosts, dns or user 
page in a list, but you cannot then refine the search. This is also 
true of ipa host-find and ipa hostgroup-find on the command line. Is 
this a bug in IPA4.1? Is it a schema issue? Is it just because we 
still have an IPA3 server running the show and an IPA4 replica? I 
can't really justify dropping our production IPA3 servers, if 
searching for records doesn't work in IPA4.1.


I still appear to be able to search in the UI of one of our other 
IPA3 servers, despite the fact it has had its schema updated and it 
has been connected to the new IPA4 server.


Thanks in advance for any help anyone can offer.

Cheers

Alex


Hello,

can you provide more info please:

* are you kinited as admin user?
* does ipa dnszone-find returns all results?
* does ipa dnszone-find  return something?
* does ipa dnszone-show  return the zone?

We had issue with access control, where non admin users cannot search 
for zones, I'm not sure about hosts, and host groups.
I do not think that this is a schema upgrade issue nor related to 
Dogtag 10.


Martin


Hi Martin,

thanks for the quick response. So, I have not kinited as the admin 
user, however as root and as my own username (A member of the admins 
group in IPA), all of the commands you requested that I test, work 
fine. As it turns out, I can run all of the following on the command 
line, as my user, or as root and it all works fine. My colleague who 
attempted to do so this morning under his username, can do so if he 
kinits to admin. So I'm assuming the CLI bit, might be an ACL issue? 
Unfortunately, my user still cannot search for hosts, hostgroups, or 
DNS entries within the UI.


ipa user-find - returns a list of 100 users
ipa user-find $username - returns the details of that user
ipa host-find returns a list of 100 hosts
ipa host-find $hostname - returns the details of the host
ipa host-find $partial-hostname - returns a list of hosts which have 
the search string inside their hostname

ipa hostgroup-find - returns a list of hostgroups
ipa hostgroup-find $hostgroupname - returns details of the hostgroup

Regards

Alex


If I understand correctly, you as admin group user, can search in CLI 
and cannot search in webUI? That is weird.


For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS 
disallow some queries from user that are not in admin group.


Martin

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10

[Alex Williams]

On 07/10/15 09:53, Martin Basti wrote:



On 10/07/2015 09:49 AM, Alex Williams wrote:

Hi guys,

yesterday I finally managed to get our IPA3.0.0 servers in a state 
that I could upgrade the schema to dogtag 10, using the migration 
script and launched a new RHEL7.1 IPA4.1 server as a replica. 
Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old 
RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be 
our CRL master), I can no longer search for hosts or DNS entries, or 
host groups, either in the UI, or on the command line.


They're there, they show up when you go to the hosts, dns or user 
page in a list, but you cannot then refine the search. This is also 
true of ipa host-find and ipa hostgroup-find on the command line. Is 
this a bug in IPA4.1? Is it a schema issue? Is it just because we 
still have an IPA3 server running the show and an IPA4 replica? I 
can't really justify dropping our production IPA3 servers, if 
searching for records doesn't work in IPA4.1.


I still appear to be able to search in the UI of one of our other 
IPA3 servers, despite the fact it has had its schema updated and it 
has been connected to the new IPA4 server.


Thanks in advance for any help anyone can offer.

Cheers

Alex


Hello,

can you provide more info please:

* are you kinited as admin user?
* does ipa dnszone-find returns all results?
* does ipa dnszone-find  return something?
* does ipa dnszone-show  return the zone?

We had issue with access control, where non admin users cannot search 
for zones, I'm not sure about hosts, and host groups.
I do not think that this is a schema upgrade issue nor related to 
Dogtag 10.


Martin


Hi Martin,

thanks for the quick response. So, I have not kinited as the admin user, 
however as root and as my own username (A member of the admins group in 
IPA), all of the commands you requested that I test, work fine. As it 
turns out, I can run all of the following on the command line, as my 
user, or as root and it all works fine. My colleague who attempted to do 
so this morning under his username, can do so if he kinits to admin. So 
I'm assuming the CLI bit, might be an ACL issue? Unfortunately, my user 
still cannot search for hosts, hostgroups, or DNS entries within the UI.


ipa user-find - returns a list of 100 users
ipa user-find $username - returns the details of that user
ipa host-find returns a list of 100 hosts
ipa host-find $hostname - returns the details of the host
ipa host-find $partial-hostname - returns a list of hosts which have the 
search string inside their hostname

ipa hostgroup-find - returns a list of hostgroups
ipa hostgroup-find $hostgroupname - returns details of the hostgroup

Regards

Alex

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Cant setup replica (freeipa 4.1.3), problem with pki

[Łukasz Jaworski]

Looks like system is missing ca cert (should it be added during 
ipa-replica-install?)
I don't know if missing cert is main problem in my case, but I made some tests:

try 1:
openssl s_client -connect `hostname -f`:8443
(…)
Verify return code: 19 (self signed certificate in certificate chain)

try 2:
openssl s_client -connect `hostname -f`:8443 -CAfile /etc/ipa/ca.crt
(…)
Verify return code: 0 (ok)


After I've added ipa.cert into /etc/pki/tls/cert.pem
cat /etc/ipa/ca.crt >> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

try 3:
openssl s_client -connect `hostname -f`:8443
(…)
Verify return code: 0 (ok)


Best regards,
Ender
-- 
Łukasz Jaworski

Wiadomość napisana przez Łukasz Jaworski  w dniu 7 paź 2015, 
o godz. 08:35:

> Hi,
> 
> I have problem with setup new replicas.
> I tried setup two replicas, both failed with the same error.
> 
> environment:
> Fedora 21
> 
> packages:
> freeipa-server-4.1.3-2.fc21.x86_64
> 389-ds-base-1.3.3.8-1.fc21.x86_64
> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64
> pki-server-10.2.0-5.fc21.noarch
> 
> same on server and replicas
> 
> 
> Output from ipa-replica-install:
> (…)
> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 
> seconds
>  [1/22]: creating certificate server user  
>  [2/22]: configuring certificate server instance
>  [3/22]: stopping certificate server instance to update CS.cfg
>  [4/22]: backing up CS.cfg
>  [5/22]: disabling nonces
>  [6/22]: set up CRL publishing
>  [7/22]: enable PKIX certificate path discovery and validation
>  [8/22]: starting certificate server instance
>  [error] RuntimeError: CA did not start in 300.0s
> 
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> 
>> From /var/log/ipareplica.log
> 2015-10-07T06:25:58Z DEBUG The CA status is: check interrupted
> 2015-10-07T06:25:58Z DEBUG Waiting for CA to start...
> 2015-10-07T06:25:59Z DEBUG Starting external process
> 2015-10-07T06:25:59Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' 
> '--no-check-certificate' 'https://182.example.com:8443/ca/admin/c
> a/getStatus'
> 2015-10-07T06:25:59Z DEBUG Process finished, return code=8
> 2015-10-07T06:25:59Z DEBUG stdout=
> 2015-10-07T06:25:59Z DEBUG stderr=--2015-10-07 08:25:59--  
> https://182.example.com:8443/ca/admin/ca/getStatus
> Resolving 182.example.com (182.example.com)... xx.xx.xx.xx
> Connecting to 182.example.com (182.example.com)|xx.xx.xx.xx|:8443... 
> connected.
> WARNING: cannot verify 182.example.com's certificate, issued by 
> ‘CN=Certificate Authority,O=ecample.com’:
>  Self-signed certificate encountered.
> HTTP request sent, awaiting response... 
>  HTTP/1.1 500 Internal Server Error
>  Server: Apache-Coyote/1.1
>  Content-Type: text/html;charset=utf-8
>  Content-Language: en
>  Content-Length: 2923
>  Date: Wed, 07 Oct 2015 06:25:59 GMT
>  Connection: close
> 2015-10-07 08:25:59 ERROR 500: Internal Server Error.
> 
> Any idea?
> 
> Best regards,
> Ender
> 
> -- 
> Łukasz Jaworski
> 
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Slow SSH login for IPA users only

[Guillem Liarte]

All,

I have an IPA 4.1 installation that works perfectly. We just suffer from
slow logins ( this is also slow in other operations such invoking SUDO )

IPA user:

1st. login: 30 seconds
2nd login: 8 seconds
3rd  login: 6.5 seconds
4rth login: 20 seconds

Local user:

Consistently under 2  seconds

In SSH have tried:

Setting UseDNS to no
Setting GSSAPIAuthentication to no

I have tried various things that would work on an slow SSH, with no effect.
In fact, local users have no problem.

DNS both forward and reverse works well, works fast and gives consistent
results. That is no the issue.

While trying to find out more about the issue, I see that after the client
has connected, it spends most of the time here:

[...]
debug2: input_userauth_pk_ok: fp
e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx
debug3: sign_and_send_pubkey: RSA
e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx
debug1: Authentication succeeded (publickey).
[...]

At first I though it might be the key retrival from the IPA service, but it
is actually quite fast:

time /usr/bin/sss_ssh_authorizedkeys testuser
real0m0.209s

We have all the configration files just as they were after installing the
ipa-client. The only modification was made to sshd_config as  these two
lines:

AuthorizedKeysCommand  /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

I also tried removing the _srv_ in the ipa server line in sssd.conf, but
that did not make any difference either.

So, in brief:

- SSH is fast for local users
- authorized keys get retrieved quickly
- no DNS issues.
- IPA users take from 6 to 30 seconds to login (and also to perform sudo
invocations)
- While watching ssh logins, for  ipa users, it takes a long time to pass
these two:

   - input_userauth_pk_ok
   - sign_and_send_pubkey

Could someone give me an idea of what to try next?

Thanks!
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10

[Martin Basti]

On 10/07/2015 12:10 PM, Alex Williams wrote:

On 07/10/15 10:57, Martin Basti wrote:



On 10/07/2015 11:23 AM, Alex Williams wrote:

On 07/10/15 09:53, Martin Basti wrote:



On 10/07/2015 09:49 AM, Alex Williams wrote:

Hi guys,

yesterday I finally managed to get our IPA3.0.0 servers in a state 
that I could upgrade the schema to dogtag 10, using the migration 
script and launched a new RHEL7.1 IPA4.1 server as a replica. 
Unfortunately, in both the new RHEL7.1 IPA4.1 server AND the old 
RHEL6.6 IPA3.0.0 server that I replicated from (Also happens to be 
our CRL master), I can no longer search for hosts or DNS entries, 
or host groups, either in the UI, or on the command line.


They're there, they show up when you go to the hosts, dns or user 
page in a list, but you cannot then refine the search. This is 
also true of ipa host-find and ipa hostgroup-find on the command 
line. Is this a bug in IPA4.1? Is it a schema issue? Is it just 
because we still have an IPA3 server running the show and an IPA4 
replica? I can't really justify dropping our production IPA3 
servers, if searching for records doesn't work in IPA4.1.


I still appear to be able to search in the UI of one of our other 
IPA3 servers, despite the fact it has had its schema updated and 
it has been connected to the new IPA4 server.


Thanks in advance for any help anyone can offer.

Cheers

Alex


Hello,

can you provide more info please:

* are you kinited as admin user?
* does ipa dnszone-find returns all results?
* does ipa dnszone-find  return something?
* does ipa dnszone-show  return the zone?

We had issue with access control, where non admin users cannot 
search for zones, I'm not sure about hosts, and host groups.
I do not think that this is a schema upgrade issue nor related to 
Dogtag 10.


Martin


Hi Martin,

thanks for the quick response. So, I have not kinited as the admin 
user, however as root and as my own username (A member of the admins 
group in IPA), all of the commands you requested that I test, work 
fine. As it turns out, I can run all of the following on the command 
line, as my user, or as root and it all works fine. My colleague who 
attempted to do so this morning under his username, can do so if he 
kinits to admin. So I'm assuming the CLI bit, might be an ACL issue? 
Unfortunately, my user still cannot search for hosts, hostgroups, or 
DNS entries within the UI.


ipa user-find - returns a list of 100 users
ipa user-find $username - returns the details of that user
ipa host-find returns a list of 100 hosts
ipa host-find $hostname - returns the details of the host
ipa host-find $partial-hostname - returns a list of hosts which have 
the search string inside their hostname

ipa hostgroup-find - returns a list of hostgroups
ipa hostgroup-find $hostgroupname - returns details of the hostgroup

Regards

Alex


If I understand correctly, you as admin group user, can search in CLI 
and cannot search in webUI? That is weird.


For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS 
disallow some queries from user that are not in admin group.


Martin


Hi Martin,

yes, that's exactly right, we seem to be able to search in the CLI, 
provided we're in the admin group, or kinit to the admin user. For 
some reason though, searching in the UI brings back nothing at all. It 
works ok for users, but not for hosts, hostgroups, or DNS entries. All 
of the entries are there, they are listed in full when you visit the 
respective page, but even searching for a full hostname doesn't work, 
let alone part of it. CLI is always an option obviously, but we don't 
really want everyone who uses this to have to use the CLI, just to 
search for a hostname or DNS entry.
Please login in webUI as admin and try search, in this case search 
should work, if not, there is something broken.


I found related tickets:
https://fedorahosted.org/freeipa/ticket/5055
https://fedorahosted.org/freeipa/ticket/5130

But I found nothing about hosts and hostsgroup, I will prepare test 
environment and try.


I've also verified that replication of things like hosts and DNS 
entries is working perfectly well between the IPA4 and IPA3 servers. 
If I add a new DNS entry in IPA3, it shows up immediately in IPA4 and 
I can then delete it in IPA4 and it's removed instantly from the IPA3 
server.


Cheers

Alex



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] ACI for full replica

[Nicola Canepa]

Hello, I'm trying to replicate a subtree of the data from FreeIPA to a 
"foreign" LDAP server, by using LSC (http://lsc-project.org).
The replication seems to work correctly, but I was unable to create an 
user (maybe even not visible from the web GUI) which could read 
userPassword field.

Which ACI/Role/Group should I use for this purpose?

Thank you for any hint: I did not find such information inside the 
documentation.


Nicola

--

Nicola Canepa
Tel: +39-0522-399-3474
canep...@mmfg.it
---
Il contenuto della presente comunicazione è riservato e destinato 
esclusivamente ai destinatari indicati. Nel caso in cui sia ricevuto da persona 
diversa dal destinatario sono proibite la diffusione, la distribuzione e la 
copia. Nel caso riceveste la presente per errore, Vi preghiamo di informarci e 
di distruggerlo e/o cancellarlo dal Vostro computer, senza utilizzare i dati 
contenuti. La presente comunicazione (comprensiva dei documenti allegati) non 
avrà valore di proposta contrattuale e/o accettazione di proposte provenienti 
dal destinatario, nè rinuncia o riconoscimento di diritti, debiti e/o crediti, 
nè sarà impegnativa, qualora non sia sottoscritto successivo accordo da chi può 
validamente obbligarci. Non deriverà alcuna responsabilità precontrattuale a 
ns. carico, se la presente non sia seguita da contratto sottoscritto dalle 
parti.

The content of the above communication is strictly confidential and reserved 
solely for the referred addressees. In the event of receipt by persons 
different from the addressee, copying, alteration and distribution are 
forbidden. If received by mistake we ask you to inform us and to destroy and/or 
delete from your computer without using the data herein contained. The present 
message (eventual annexes inclusive) shall not be considered a contractual 
proposal and/or acceptance of offer from the addressee, nor waiver recognizance 
of rights, debts  and/or credits, nor shall it be binding when not executed as 
a subsequent agreement by persons who could lawfully represent us. No 
pre-contractual liability shall apply to us when the present communication is 
not followed by any binding agreement between the parties.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Slow SSH login for IPA users only

[Sumit Bose]

On Wed, Oct 07, 2015 at 12:07:08PM +0200, Guillem Liarte wrote:
> All,
> 
> I have an IPA 4.1 installation that works perfectly. We just suffer from
> slow logins ( this is also slow in other operations such invoking SUDO )
> 
> IPA user:
> 
> 1st. login: 30 seconds
> 2nd login: 8 seconds
> 3rd  login: 6.5 seconds
> 4rth login: 20 seconds
> 
> Local user:
> 
> Consistently under 2  seconds
> 
> In SSH have tried:
> 
> Setting UseDNS to no
> Setting GSSAPIAuthentication to no
> 
> I have tried various things that would work on an slow SSH, with no effect.
> In fact, local users have no problem.
> 
> DNS both forward and reverse works well, works fast and gives consistent
> results. That is no the issue.
> 
> While trying to find out more about the issue, I see that after the client
> has connected, it spends most of the time here:
> 
> [...]
> debug2: input_userauth_pk_ok: fp
> e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx
> debug3: sign_and_send_pubkey: RSA
> e9:45:2d:52:97:f7:16:5b:2d:83:2f:2e:d9:xx:xx:xx
> debug1: Authentication succeeded (publickey).
> [...]
> 
> At first I though it might be the key retrival from the IPA service, but it
> is actually quite fast:
> 
> time /usr/bin/sss_ssh_authorizedkeys testuser
> real0m0.209s
> 
> We have all the configration files just as they were after installing the
> ipa-client. The only modification was made to sshd_config as  these two
> lines:
> 
> AuthorizedKeysCommand  /usr/bin/sss_ssh_authorizedkeys
> AuthorizedKeysCommandUser nobody
> 
> I also tried removing the _srv_ in the ipa server line in sssd.conf, but
> that did not make any difference either.
> 
> So, in brief:
> 
> - SSH is fast for local users
> - authorized keys get retrieved quickly
> - no DNS issues.
> - IPA users take from 6 to 30 seconds to login (and also to perform sudo
> invocations)
> - While watching ssh logins, for  ipa users, it takes a long time to pass
> these two:
> 
>- input_userauth_pk_ok
>- sign_and_send_pubkey
> 
> Could someone give me an idea of what to try next?

Please check the SSSD logs especailly the ones for the domain. You might
need to increase the debug_level, please see
https://fedorahosted.org/sssd/wiki/Troubleshooting for details.

bye,
Sumit

> 
> Thanks!

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Searching for things in the UI no longer seems to work, neither does ipa host-find or hostgroup-find after schema upgrade to dogtag 10

[Alex Williams]

On 07/10/15 11:31, Martin Basti wrote:



On 10/07/2015 12:28 PM, Martin Basti wrote:



On 10/07/2015 12:10 PM, Alex Williams wrote:

On 07/10/15 10:57, Martin Basti wrote:



On 10/07/2015 11:23 AM, Alex Williams wrote:

On 07/10/15 09:53, Martin Basti wrote:



On 10/07/2015 09:49 AM, Alex Williams wrote:

Hi guys,

yesterday I finally managed to get our IPA3.0.0 servers in a 
state that I could upgrade the schema to dogtag 10, using the 
migration script and launched a new RHEL7.1 IPA4.1 server as a 
replica. Unfortunately, in both the new RHEL7.1 IPA4.1 server 
AND the old RHEL6.6 IPA3.0.0 server that I replicated from (Also 
happens to be our CRL master), I can no longer search for hosts 
or DNS entries, or host groups, either in the UI, or on the 
command line.


They're there, they show up when you go to the hosts, dns or 
user page in a list, but you cannot then refine the search. This 
is also true of ipa host-find and ipa hostgroup-find on the 
command line. Is this a bug in IPA4.1? Is it a schema issue? Is 
it just because we still have an IPA3 server running the show 
and an IPA4 replica? I can't really justify dropping our 
production IPA3 servers, if searching for records doesn't work 
in IPA4.1.


I still appear to be able to search in the UI of one of our 
other IPA3 servers, despite the fact it has had its schema 
updated and it has been connected to the new IPA4 server.


Thanks in advance for any help anyone can offer.

Cheers

Alex


Hello,

can you provide more info please:

* are you kinited as admin user?
* does ipa dnszone-find returns all results?
* does ipa dnszone-find  return something?
* does ipa dnszone-show  return the zone?

We had issue with access control, where non admin users cannot 
search for zones, I'm not sure about hosts, and host groups.
I do not think that this is a schema upgrade issue nor related to 
Dogtag 10.


Martin


Hi Martin,

thanks for the quick response. So, I have not kinited as the admin 
user, however as root and as my own username (A member of the 
admins group in IPA), all of the commands you requested that I 
test, work fine. As it turns out, I can run all of the following 
on the command line, as my user, or as root and it all works fine. 
My colleague who attempted to do so this morning under his 
username, can do so if he kinits to admin. So I'm assuming the CLI 
bit, might be an ACL issue? Unfortunately, my user still cannot 
search for hosts, hostgroups, or DNS entries within the UI.


ipa user-find - returns a list of 100 users
ipa user-find $username - returns the details of that user
ipa host-find returns a list of 100 hosts
ipa host-find $hostname - returns the details of the host
ipa host-find $partial-hostname - returns a list of hosts which 
have the search string inside their hostname

ipa hostgroup-find - returns a list of hostgroups
ipa hostgroup-find $hostgroupname - returns details of the hostgroup

Regards

Alex


If I understand correctly, you as admin group user, can search in 
CLI and cannot search in webUI? That is weird.


For CLI part, IIRC this bug has been fixed in IPA 4.2, ACI in DS 
disallow some queries from user that are not in admin group.


Martin


Hi Martin,

yes, that's exactly right, we seem to be able to search in the CLI, 
provided we're in the admin group, or kinit to the admin user. For 
some reason though, searching in the UI brings back nothing at all. 
It works ok for users, but not for hosts, hostgroups, or DNS 
entries. All of the entries are there, they are listed in full when 
you visit the respective page, but even searching for a full 
hostname doesn't work, let alone part of it. CLI is always an option 
obviously, but we don't really want everyone who uses this to have 
to use the CLI, just to search for a hostname or DNS entry.
Please login in webUI as admin and try search, in this case search 
should work, if not, there is something broken.


I found related tickets:
https://fedorahosted.org/freeipa/ticket/5055
https://fedorahosted.org/freeipa/ticket/5130

But I found nothing about hosts and hostsgroup, I will prepare test 
environment and try.
Nevermind, here is hosts/hostgroup/service/netgroup ticket 
https://fedorahosted.org/freeipa/ticket/5167


I've also verified that replication of things like hosts and DNS 
entries is working perfectly well between the IPA4 and IPA3 servers. 
If I add a new DNS entry in IPA3, it shows up immediately in IPA4 
and I can then delete it in IPA4 and it's removed instantly from the 
IPA3 server.


Cheers

Alex








Hi Martin,

thanks for that, that does in fact seem to be the issue. As per your 
instructions, logging in as 'admin' to the UI, allows the search feature 
to work. That does beg the question as to how my user can use its 
kerberos ticket on the CLI, but not in the UI though? Either way, the 
fix for the issue looks to be trivial (Replacing a few python files by 
the looks of things), so I'll give that a go and at worst, I guess we 
may have to 

Re: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts

[thierry bordaz]

On 10/07/2015 11:19 AM, Martin Kosek wrote:

On 10/05/2015 02:13 PM, Dominik Korittki wrote:


Am 01.10.2015 um 21:52 schrieb Rob Crittenden:

Dominik Korittki wrote:

Hello folks,

I am running two FreeIPA Servers with around 100 users and around 15.000
hosts, which are used by users to login via ssh. The FreeIPA servers
(which are Centos 7.0) ran good for a while, but as more and more hosts
got migrated to serve as FreeIPA hosts, it started to get slow and
unstable.

For example, its hard to maintain hostgroups, which have more than 1.000
hosts. The ipa host-* commands are getting slower as the hostgroup
grows. Is this normal?

You mean the ipa hostgroup-* commands? Whenever the entry is displayed
(show and add) it needs to dereference all members so yes, it is
understandable that it gets somewhat slower with more members. How slow
are we talking about?


We also experience random dirsrv segfaults. Here's a dmesg line from the
latest:

[690787.647261] traps: ns-slapd[5217] general protection ip:7f8d6b6d6bc1
sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b65+1b6000]

You probably want to start here:
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes

A stacktrace from the latest crash is attached to this email. After restarting
the service, this is what I get in /var/log/dirsrv/slapd-INTERNAL/errors
(hostname is ipa01.internal):

Ludwig or Thierry, can you please take a look at the stack and file 389-DS
ticket if appropriate?


Hello Dominik,

DS is crashing during a BIND and from the arguments values we can guess 
it was due to a heap corruption that corrupted it operation pblock.
This bind operation was likely victim of the heap corruption more than 
responsible of it.


Using valgrind is the best way to track such problem but as you already 
suffer from bad performance I doubt it would be acceptable.

How frequently does it crash ? did you identify a kind of test case ?

thanks
thierry

[05/Oct/2015:13:51:30 +0200] - slapd started.  Listening on All Interfaces port
389 for LDAP requests
[05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636 for LDAPS
requests
[05/Oct/2015:13:51:30 +0200] - Listening on /var/run/slapd-INTERNAL.socket for
LDAPI requests
[05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind - Error: could
not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local
error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
Minor code may provide more information (No Kerberos credentials available))
errno 0 (Success)
[05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not perform
interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local
error)
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI auth
failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (No Kerberos
credentials available))
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog program -
agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN
54bea4800060 not found, we aren't as up to date, or we purged
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Data required
to update replica has been purged. The replica must be reinitialized.
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): Incremental
update failed and requires administrator action
[05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with GSSAPI auth
resumed


These lines are present since a replayed a ldif dump from ipa02 to ipa01, but i
didn't think that it related to the segfault problem (therefore i said there
are no related problems in the logfile).

But I am starting to believe that these errors could be in relation to each 
other.


Kind regards,
Dominik Korittki





Nothing in /var/log/dirsrv/slapd-INTERNAL/errors, which relates to the
problem.

Not sure about that anymore.


I'm thinking about migrating to latest CentOS 7 FreeIPA 4, but does that
solve my problems?

FreeIPA server version is 3.3.3-28.el7.centos
389-ds-base.x86_64 is 1.3.1.6-26.el7_0



Kind regards,
Dominik Korittki









--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ACI for full replica

[Rob Crittenden]

Nicola Canepa wrote:
> Hello, I'm trying to replicate a subtree of the data from FreeIPA to a
> "foreign" LDAP server, by using LSC (http://lsc-project.org).
> The replication seems to work correctly, but I was unable to create an
> user (maybe even not visible from the web GUI) which could read
> userPassword field.
> Which ACI/Role/Group should I use for this purpose?
> 
> Thank you for any hint: I did not find such information inside the
> documentation.

Depending on the type of bind user you're using you'd need to add your
own permission or ACI to grant read on userPassword. I'd tread very
carefully here and triple check that the ACI does only what you need and
doesn't otherwise leak data, and especially watch those who can assign
roles to avoid accidental disclosure.

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts

[Dominik Korittki]

Am 07.10.2015 um 15:25 schrieb thierry bordaz:

On 10/07/2015 11:19 AM, Martin Kosek wrote:

On 10/05/2015 02:13 PM, Dominik Korittki wrote:


Am 01.10.2015 um 21:52 schrieb Rob Crittenden:

Dominik Korittki wrote:

Hello folks,

I am running two FreeIPA Servers with around 100 users and around
15.000
hosts, which are used by users to login via ssh. The FreeIPA servers
(which are Centos 7.0) ran good for a while, but as more and more
hosts
got migrated to serve as FreeIPA hosts, it started to get slow and
unstable.

For example, its hard to maintain hostgroups, which have more than
1.000
hosts. The ipa host-* commands are getting slower as the hostgroup
grows. Is this normal?

You mean the ipa hostgroup-* commands? Whenever the entry is displayed
(show and add) it needs to dereference all members so yes, it is
understandable that it gets somewhat slower with more members. How slow
are we talking about?


We also experience random dirsrv segfaults. Here's a dmesg line
from the
latest:

[690787.647261] traps: ns-slapd[5217] general protection
ip:7f8d6b6d6bc1
sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b65+1b6000]

You probably want to start here:
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes

A stacktrace from the latest crash is attached to this email. After
restarting
the service, this is what I get in /var/log/dirsrv/slapd-INTERNAL/errors
(hostname is ipa01.internal):

Ludwig or Thierry, can you please take a look at the stack and file
389-DS
ticket if appropriate?


Hello Dominik,

DS is crashing during a BIND and from the arguments values we can guess
it was due to a heap corruption that corrupted it operation pblock.
This bind operation was likely victim of the heap corruption more than
responsible of it.

Using valgrind is the best way to track such problem but as you already
suffer from bad performance I doubt it would be acceptable.
How frequently does it crash ? did you identify a kind of test case ?


At first the crashes happenend at a daily basis. Simply restarting the 
dirsrv daemon resolved the issue for another day but later on the daemon 
did not survive more than 15 minutes most of the time. There were 
exceptions though. Sometimes the daemon ran for several hours until it 
chrashed.
I did not really identify a testcase. However, I supposed it could have 
something to do with replication, as I have seen replication related 
errors in dirsrv error log (mentioned in an earlier mail in this topic).


So did the following:
ipa01 has a replication agreement with ipa02. ipa01 was the one with 
segfaults. I removed ipa01 from the replication agreement 
(ipa-replica-manage del), did an ipa-server-install --uninstall on ipa01 
and created ipa01 as a replica of ipa02. Since then I did not experience 
any crashes (for now).
Instead i'm having trouble rebuilding a clean replication agreement (old 
RUV stuff still in database), but thats another story I will eventually 
post on the mailinglist as a new topic.


As for valgrind: Never used it before. Is there a handy explanation of 
how to use it in combination with 389ds? If I still experience those 
crashes and I get it managed to use I could try it out.



Kind regards,
Dominik Korittki



thanks
thierry

[05/Oct/2015:13:51:30 +0200] - slapd started.  Listening on All
Interfaces port
389 for LDAP requests
[05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636
for LDAPS
requests
[05/Oct/2015:13:51:30 +0200] - Listening on
/var/run/slapd-INTERNAL.socket for
LDAPI requests
[05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind -
Error: could
not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2
(Local
error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure.
Minor code may provide more information (No Kerberos credentials
available))
errno 0 (Success)
[05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not perform
interactive bind for id [] authentication mechanism [GSSAPI]: error
-2 (Local
error)
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with
GSSAPI auth
failed: LDAP error -2 (Local error) (SASL(-1): generic failure:
GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (No
Kerberos
credentials available))
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog program -
agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN
54bea4800060 not found, we aren't as up to date, or we purged
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389):
Data required
to update replica has been purged. The replica must be reinitialized.
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -
agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389):
Incremental
update failed and requires administrator action
[05/Oct/2015:13:51:33 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa02.internal" 

Re: [Freeipa-users] FreeIPA 3.3 performance issues with many hosts

[thierry bordaz]

On 10/07/2015 05:03 PM, Dominik Korittki wrote:



Am 07.10.2015 um 15:25 schrieb thierry bordaz:

On 10/07/2015 11:19 AM, Martin Kosek wrote:

On 10/05/2015 02:13 PM, Dominik Korittki wrote:


Am 01.10.2015 um 21:52 schrieb Rob Crittenden:

Dominik Korittki wrote:

Hello folks,

I am running two FreeIPA Servers with around 100 users and around
15.000
hosts, which are used by users to login via ssh. The FreeIPA servers
(which are Centos 7.0) ran good for a while, but as more and more
hosts
got migrated to serve as FreeIPA hosts, it started to get slow and
unstable.

For example, its hard to maintain hostgroups, which have more than
1.000
hosts. The ipa host-* commands are getting slower as the hostgroup
grows. Is this normal?
You mean the ipa hostgroup-* commands? Whenever the entry is 
displayed

(show and add) it needs to dereference all members so yes, it is
understandable that it gets somewhat slower with more members. How 
slow

are we talking about?


We also experience random dirsrv segfaults. Here's a dmesg line
from the
latest:

[690787.647261] traps: ns-slapd[5217] general protection
ip:7f8d6b6d6bc1
sp:7f8d3aff2a88 error:0 in libc-2.17.so[7f8d6b65+1b6000]

You probably want to start here:
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes

A stacktrace from the latest crash is attached to this email. After
restarting
the service, this is what I get in 
/var/log/dirsrv/slapd-INTERNAL/errors

(hostname is ipa01.internal):

Ludwig or Thierry, can you please take a look at the stack and file
389-DS
ticket if appropriate?


Hello Dominik,

DS is crashing during a BIND and from the arguments values we can guess
it was due to a heap corruption that corrupted it operation pblock.
This bind operation was likely victim of the heap corruption more than
responsible of it.

Using valgrind is the best way to track such problem but as you already
suffer from bad performance I doubt it would be acceptable.
How frequently does it crash ? did you identify a kind of test case ?


At first the crashes happenend at a daily basis. Simply restarting the 
dirsrv daemon resolved the issue for another day but later on the 
daemon did not survive more than 15 minutes most of the time. There 
were exceptions though. Sometimes the daemon ran for several hours 
until it chrashed.
I did not really identify a testcase. However, I supposed it could 
have something to do with replication, as I have seen replication 
related errors in dirsrv error log (mentioned in an earlier mail in 
this topic).
heap corruption are usually dynamic and if the server became more and 
more slow, it could change the dynamic in favor of heap corruption.


So did the following:
ipa01 has a replication agreement with ipa02. ipa01 was the one with 
segfaults. I removed ipa01 from the replication agreement 
(ipa-replica-manage del), did an ipa-server-install --uninstall on 
ipa01 and created ipa01 as a replica of ipa02. Since then I did not 
experience any crashes (for now).
Instead i'm having trouble rebuilding a clean replication agreement 
(old RUV stuff still in database), but thats another story I will 
eventually post on the mailinglist as a new topic.


As for valgrind: Never used it before. Is there a handy explanation of 
how to use it in combination with 389ds? If I still experience those 
crashes and I get it managed to use I could try it out.
You may follow this procedure 
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-memory-growthinvalid-access-with-valgrind 
(but remove --leak-check=yes because this is not a leak issue)


thanks
thierry



Kind regards,
Dominik Korittki



thanks
thierry

[05/Oct/2015:13:51:30 +0200] - slapd started.  Listening on All
Interfaces port
389 for LDAP requests
[05/Oct/2015:13:51:30 +0200] - Listening on All Interfaces port 636
for LDAPS
requests
[05/Oct/2015:13:51:30 +0200] - Listening on
/var/run/slapd-INTERNAL.socket for
LDAPI requests
[05/Oct/2015:13:51:30 +0200] slapd_ldap_sasl_interactive_bind -
Error: could
not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2
(Local
error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure.
Minor code may provide more information (No Kerberos credentials
available))
errno 0 (Success)
[05/Oct/2015:13:51:30 +0200] slapi_ldap_bind - Error: could not 
perform

interactive bind for id [] authentication mechanism [GSSAPI]: error
-2 (Local
error)
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -
agmt="cn=meToipa02.internal" (ipa02:389): Replication bind with
GSSAPI auth
failed: LDAP error -2 (Local error) (SASL(-1): generic failure:
GSSAPI Error:
Unspecified GSS failure.  Minor code may provide more information (No
Kerberos
credentials available))
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin - changelog 
program -

agmt="cn=masterAgreement1-ipa02.internal-pki-tomcat" (ipa02:389): CSN
54bea4800060 not found, we aren't as up to date, or we purged
[05/Oct/2015:13:51:30 +0200] NSMMReplicationPlugin -

Re: [Freeipa-users] Cant setup replica (freeipa 4.1.3), problem with pki

[Rob Crittenden]

Łukasz Jaworski wrote:
> Hi,
> 
> I have problem with setup new replicas.
> I tried setup two replicas, both failed with the same error.
> 
> environment:
> Fedora 21
> 
> packages:
> freeipa-server-4.1.3-2.fc21.x86_64
> 389-ds-base-1.3.3.8-1.fc21.x86_64
> 389-ds-base-libs-1.3.3.8-1.fc21.x86_64
> pki-server-10.2.0-5.fc21.noarch
> 
> same on server and replicas
> 
> 
> Output from ipa-replica-install:
> (…)
> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 
> seconds
>   [1/22]: creating certificate server user  
>   [2/22]: configuring certificate server instance
>   [3/22]: stopping certificate server instance to update CS.cfg
>   [4/22]: backing up CS.cfg
>   [5/22]: disabling nonces
>   [6/22]: set up CRL publishing
>   [7/22]: enable PKIX certificate path discovery and validation
>   [8/22]: starting certificate server instance
>   [error] RuntimeError: CA did not start in 300.0s
> 
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> 
>>From /var/log/ipareplica.log
> 2015-10-07T06:25:58Z DEBUG The CA status is: check interrupted
> 2015-10-07T06:25:58Z DEBUG Waiting for CA to start...
> 2015-10-07T06:25:59Z DEBUG Starting external process
> 2015-10-07T06:25:59Z DEBUG args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' 
> '--no-check-certificate' 'https://182.example.com:8443/ca/admin/c
> a/getStatus'
> 2015-10-07T06:25:59Z DEBUG Process finished, return code=8
> 2015-10-07T06:25:59Z DEBUG stdout=
> 2015-10-07T06:25:59Z DEBUG stderr=--2015-10-07 08:25:59--  
> https://182.example.com:8443/ca/admin/ca/getStatus
> Resolving 182.example.com (182.example.com)... xx.xx.xx.xx
> Connecting to 182.example.com (182.example.com)|xx.xx.xx.xx|:8443... 
> connected.
> WARNING: cannot verify 182.example.com's certificate, issued by 
> ‘CN=Certificate Authority,O=ecample.com’:
>   Self-signed certificate encountered.
> HTTP request sent, awaiting response... 
>   HTTP/1.1 500 Internal Server Error
>   Server: Apache-Coyote/1.1
>   Content-Type: text/html;charset=utf-8
>   Content-Language: en
>   Content-Length: 2923
>   Date: Wed, 07 Oct 2015 06:25:59 GMT
>   Connection: close
> 2015-10-07 08:25:59 ERROR 500: Internal Server Error.
> 
> Any idea?
> 

You'll need to check the dogtag logs for errors. Start with
/var/log/pki/pki-tomcat/ca/debug

rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA DMZ topology

[Baird, Josh]

I'm also interested in how people are handling this - especially when using AD 
Trusts.

When using a trust, the IPA host not only has to communicate with IPA servers, 
but with potentially every AD domain controller in your HUB site.  For us, this 
is a large number of domain controllers which means we would need a large 
number of ACL's on our firewalls to permit the IPA DMZ client access to the AD 
domain controllers.

Any suggestions?

Thanks,

Josh

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Aly Khimji
Sent: Wednesday, October 07, 2015 1:12 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] FreeIPA DMZ topology

Hey guys,

Question for you, would having a replica be the ideal solution for authorizing 
hosts in a DMZ?

Do you have any use cases for DMZ access/authorization or topologies you can 
share for DMZ zones where FreeIPA is used?

Aly


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA DMZ topology

[Aly Khimji]

Yes sorry I should expand on my question as per Josh's point my scenario
also has an AD trust involved.
I recently learned of KDC proxying but I am not sure if replica's and KDC
proxies are the preferred/accepted design solutions for DMZ's

Aly

On Wed, Oct 7, 2015 at 1:18 PM, Baird, Josh  wrote:

> I'm also interested in how people are handling this - especially when
> using AD Trusts.
>
>
>
> When using a trust, the IPA host not only has to communicate with IPA
> servers, but with potentially every AD domain controller in your HUB site.
> For us, this is a large number of domain controllers which means we would
> need a large number of ACL's on our firewalls to permit the IPA DMZ client
> access to the AD domain controllers.
>
>
>
> Any suggestions?
>
>
>
> Thanks,
>
>
>
> Josh
>
>
>
> *From:* freeipa-users-boun...@redhat.com [mailto:
> freeipa-users-boun...@redhat.com] *On Behalf Of *Aly Khimji
> *Sent:* Wednesday, October 07, 2015 1:12 PM
> *To:* freeipa-users@redhat.com
> *Subject:* [Freeipa-users] FreeIPA DMZ topology
>
>
>
> Hey guys,
>
>
>
> Question for you, would having a replica be the ideal solution for
> authorizing hosts in a DMZ?
>
>
> Do you have any use cases for DMZ access/authorization or topologies you
> can share for DMZ zones where FreeIPA is used?
>
>
>
> Aly
>
>
>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Web login problems

[Pat Gunn]

Hi,
I'm trying to build a cluster of 3 IPA (staging at this point, but
eventually later I'll make a prod version)
systems (that will reside in AWS) that will manage select systems in our
infrastructure (mostly but not entirely in AWS).
The systems will be fronted (like most of our infrastructure) with a
load-balancer that manages pooling and SSL termination; we'd like
freeipa-staging.corp.$ORGNAME.com to be the access point, and the LB will
then route that to a specific one of the three servers based on pool
settings).

The systems are running CentOS7 and have the RPM-bundled version of FreeIPA
(4.1.0). Our three IPA servers are named
freeipa-staging-[123].vpc3.$INTERNALNAME.cc - the servers that will be
managed by this will have a variety of names and locations (and
$INTERNALNAME differs from $ORGNAME but both are valid DNSnames)

After running ipa-server-install on the first box (no integrated DNS
enabled, realmname is IPA-STAGING.$ORGNAME.ORG), I modified the
ipa-rewrite.conf to trim it down to this:
RewriteEngine on
RewriteRule ^/$ /ipa/ui [L,NC,R=301]
RewriteRule ^/ipa/ui/js/freeipa/plugins.js$/ipa/wsgi/plugins.py [PT]


After the stack starts, I can kinit and run commands. Everything looks
good. The WebUI isn't working for me though - when I enter admin and the
password, I get "Your session has expired. Please re-login". By contrast,
when I give the wrong password, it tells me it's wrong.

After enabling debugging in ipa.conf, this is what I get from the httpd
error log:

[Wed Oct 07 17:29:50.370982 2015] [:error] [pid 3000] ipa: DEBUG: WSGI
wsgi_dispatch.__call__:
[Wed Oct 07 17:29:50.371088 2015] [:error] [pid 3000] ipa: DEBUG: WSGI
login_password.__call__:
[Wed Oct 07 17:29:50.371438 2015] [:error] [pid 3000] ipa: DEBUG: Obtaining
armor ccache: principal=HTTP/
freeipa-staging-1.vpc3.internalname...@ipa-staging.orgname.org
keytab=/etc/httpd/conf/ipa.keytab
ccache=/var/run/ipa_memcached/krbcc_A_admin
[Wed Oct 07 17:29:50.371534 2015] [:error] [pid 3000] ipa: DEBUG: Starting
external process
[Wed Oct 07 17:29:50.371596 2015] [:error] [pid 3000] ipa: DEBUG:
args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' 'HTTP/
freeipa-staging-1.vpc3.internalname...@ipa-staging.orgname.org'
[Wed Oct 07 17:29:50.415134 2015] [:error] [pid 3000] ipa: DEBUG: Process
finished, return code=0
[Wed Oct 07 17:29:50.415223 2015] [:error] [pid 3000] ipa: DEBUG: stdout=
[Wed Oct 07 17:29:50.415276 2015] [:error] [pid 3000] ipa: DEBUG: stderr=
[Wed Oct 07 17:29:50.415395 2015] [:error] [pid 3000] ipa: DEBUG: Starting
external process
[Wed Oct 07 17:29:50.415458 2015] [:error] [pid 3000] ipa: DEBUG:
args='/usr/bin/kinit' 'ad...@ipa-staging.orgname.org' '-T'
'/var/run/ipa_memcached/krbcc_A_admin'
[Wed Oct 07 17:29:50.486981 2015] [:error] [pid 3000] ipa: DEBUG: Process
finished, return code=0
[Wed Oct 07 17:29:50.487072 2015] [:error] [pid 3000] ipa: DEBUG:
stdout=Password for ad...@ipa-staging.orgname.org:
[Wed Oct 07 17:29:50.487079 2015] [:error] [pid 3000]
[Wed Oct 07 17:29:50.487129 2015] [:error] [pid 3000] ipa: DEBUG: stderr=
[Wed Oct 07 17:29:50.487228 2015] [:error] [pid 3000] ipa: DEBUG: kinit:
principal=ad...@ipa-staging.orgname.org returncode=0, stderr=""
[Wed Oct 07 17:29:50.487281 2015] [:error] [pid 3000] ipa: DEBUG: Cleanup
the armor ccache
[Wed Oct 07 17:29:50.487356 2015] [:error] [pid 3000] ipa: DEBUG: Starting
external process
[Wed Oct 07 17:29:50.487406 2015] [:error] [pid 3000] ipa: DEBUG:
args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin'
[Wed Oct 07 17:29:50.500419 2015] [:error] [pid 3000] ipa: DEBUG: Process
finished, return code=0
[Wed Oct 07 17:29:50.500496 2015] [:error] [pid 3000] ipa: DEBUG: stdout=
[Wed Oct 07 17:29:50.500547 2015] [:error] [pid 3000] ipa: DEBUG: stderr=
[Wed Oct 07 17:29:50.501180 2015] [:error] [pid 3000] ipa: DEBUG: no
session cookie found
[Wed Oct 07 17:29:50.501501 2015] [:error] [pid 3000] ipa: DEBUG: no
session id in request, generating empty session data with
id=738fef28e7a985fe8f01e0fc2a1c8e7d
[Wed Oct 07 17:29:50.501607 2015] [:error] [pid 3000] ipa: DEBUG: store
session: session_id=738fef28e7a985fe8f01e0fc2a1c8e7d
start_timestamp=2015-10-07T17:29:50 access_timestamp=2015-10-07T17:29:50
expiration_timestamp=1970-01-01T00:00:00
[Wed Oct 07 17:29:50.501908 2015] [:error] [pid 3000] ipa: DEBUG:
finalize_kerberos_acquisition: login_password
ccache_name="FILE:/var/run/ipa_memcached/krbcc_3000"
session_id="738fef28e7a985fe8f01e0fc2a1c8e7d"
[Wed Oct 07 17:29:50.501978 2015] [:error] [pid 3000] ipa: DEBUG: reading
ccache data from file "/var/run/ipa_memcached/krbcc_3000"
[Wed Oct 07 17:29:50.502358 2015] [:error] [pid 3000] ipa: DEBUG:
get_credential_times: principal=krbtgt/
ipa-staging.orgname@ipa-staging.orgname.org, authtime=10/07/15
17:29:50, starttime=10/07/15 17:29:50, endtime=10/08/15 17:29:50,
renew_till=01/01/70 00:00:00
[Wed Oct 07 17:29:50.502436 2015] [:error] [pid 3000] ipa: DEBUG:
KRB5_CCache 

[Freeipa-users] Certmonger and dogtag not working....issues manually renewing Server-Cert

[Gronde, Christopher (Contractor)]

I am new to FreeIPA and have inherited two IPA servers not sure if one is a 
master/slave or how they are different.  I will try to give some pertinent 
outputs below of some of the things I am seeing.  I know the Server-Cert is 
expired but can't figure out how to renew it.  There also appears to be 
Kerberos authentication issues going on as I'm trying to fix it.

#getcert list -d /etc/httpd/alias -n ipaCert
Number of certificates and requests being tracked: 2.
Request ID '20150922143354':
status: NEED_TO_SUBMIT
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB'
CA: dogtag-ipa-retrieve-agent-submit
issuer: CN=Certificate Authority,O=.GOV
subject: CN=IPA RA,O=.GOV
expires: 2013-10-09 11:45:01 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes

#certutil -V -u V -n Server-Cert -d /etc/httpd/alias
certutil: certificate is invalid: Peer's Certificate has expired.


#certutil -L -d /etc/httpd/alias -n Server-Cert
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 166 (0xa6)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=.GOV"
Validity:
Not Before: Sun Sep 22 17:46:26 2013
Not After : Wed Sep 23 17:46:26 2015
Subject: "CN=comipa02..gov,O=.GOV"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:
c6:8e:37:ee:72:82:58:78:4e:16:b8:18:f3:28:05:d9:
e5:3c:ee:01:ec:3e:28:d5:87:be:e4:74:ec:e5:27:40:
ca:9c:eb:61:a2:ad:44:c0:d9:2e:6d:93:fd:67:4c:f8:
6d:f6:f2:63:6f:e6:00:4a:2a:c4:44:f5:e7:32:50:40:
51:5b:0e:15:69:25:ef:c9:4f:47:ad:ba:90:fb:36:6d:
14:3f:04:c4:7b:c3:e6:b1:30:7b:56:2d:d3:0f:d9:2f:
c9:57:89:c7:21:8a:a6:d4:2a:63:27:6c:54:53:7b:44:
9a:0b:da:8f:b9:88:ec:b4:95:d3:5c:6c:cf:7b:dc:30:
ef:25:db:fd:89:26:7f:25:34:9d:6e:7b:b0:94:62:81:
0e:b8:d6:3e:95:0e:71:e2:3f:6b:e2:3d:f2:71:8d:4c:
ec:41:e2:fa:c7:8b:50:80:90:68:a8:88:5c:07:c6:cc:
5a:48:fc:7f:37:28:78:b3:2e:79:05:73:a5:9d:75:ae:
15:bc:55:6c:85:ab:cd:2e:44:6b:10:c2:25:d8:bb:03:
11:3f:69:44:3e:1c:ba:a3:c9:fa:36:ae:a6:6e:f4:51:
a0:74:ff:e9:31:40:51:69:d2:49:47:a8:38:7a:9b:b8:
32:04:4c:ad:6d:52:91:53:61:a3:fa:37:82:f4:38:cb
Exponent: 65537 (0x10001)
Signed Extensions:
Name: Certificate Authority Key Identifier
Key ID:
ab:01:f6:f0:b1:f6:58:15:f9:0d:e6:35:83:44:ab:50:
c3:13:4b:16

Name: Authority Information Access
Method: PKIX Online Certificate Status Protocol
Location:
URI: "http://comipa01..gov:80/ca/ocsp"

Name: Certificate Key Usage
Critical: True
Usages: Digital Signature
Non-Repudiation
Key Encipherment
Data Encipherment

Name: Extended Key Usage
TLS Web Server Authentication Certificate
TLS Web Client Authentication Certificate

Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Signature:
2d:e0:48:99:ca:e8:e3:33:40:de:9b:a9:bf:a0:37:98:
d3:22:f7:d5:ff:a6:2b:fd:b3:fc:c8:c3:f0:16:ee:a5:
44:5a:8d:d8:eb:eb:56:08:95:3e:48:2d:a1:be:a0:c2:
64:a3:55:62:ab:42:3b:e6:ff:90:3e:0f:a2:59:2a:7a:
c0:f3:81:bb:6d:27:6a:1d:12:41:89:cb:fc:cf:5d:fa:
b5:f6:6d:b9:1a:b8:fb:cc:84:3c:5d:98:da:79:64:07:
6f:c0:d1:9d:8a:e1:03:70:71:87:39:f6:fc:a0:4a:a2:
43:57:0a:dc:33:6b:f4:4e:be:0a:5b:26:83:eb:e3:57:
ad:aa:5c:d4:f7:1f:0d:38:f2:71:85:b0:27:9c:8e:57:
01:51:b5:e8:e7:a4:9f:a0:0b:bd:96:45:ac:30:86:d5:
b8:78:56:5e:29:3e:70:9d:80:b0:25:50:fc:c6:e1:a7:
0a:1c:e9:da:1d:00:1f:53:9b:fd:9b:a9:74:1b:45:8f:
7d:f0:c4:cc:ff:ae:1f:0f:3e:2d:8f:81:80:ee:27:38:
f6:5b:39:b4:54:7c:56:c5:b4:0e:93:b8:24:18:42:70:
5d:d3:7b:c9:db:be:14:22:1c:29:16:84:ab:4d:05:b0:
7b:1b:7d:e4:94:0d:39:42:71:33:94:57:16:7b:90:6f
Fingerprint (SHA-256):

DD:B0:8E:6B:5F:61:D1:7C:29:ED:CB:8C:8D:7E:9F:94:BE:40:E7:8B:AD:55:ED:14:E9:32:C4:7A:F0:0A:F3:2C
Fingerprint (SHA1):