[Freeipa-users] sudo (sssd) hangs due to ipa install/uninstall scripts

[Prasun Gera]

Version: idm 4.x on rhel 7.1

Yet again, I've discovered a problem with residual state left behind by ipa
client install and uninstall scripts. I was having some trouble with
autofs+sssd leading to users not being mapped correctly (got nobody users
for everything). So I tried theipa-client-automount --uninstall, followed
by ipa-client-install --uninstall, and then did a fresh install of the
client. The original autofs issue aside, I started getting hangs in sudo.
After spending a better part of the day, the culprit was this line in
nsswitch.conf:

sudoers: files sss sss

It turns out that the extra sss left behind is sufficient to make any sudo
command hang. Easy to reproduce too.

Regarding the original autofs problem, I don't have a conclusive
explanation yet, but explicitly adding nfsvers=3 seems to map users
correctly.

It's always scary to use these install and uninstall scripts. They always
tend to leave bits and pieces behind. Isn't there a cleaner way to achieve
this ?
-- 
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] Migrate from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1)

[Matt .]

Anyone some suggestions about this ?

I'm thinking about adding from my second 3.x master where I first need
to split that cluster to make that happen.



2015-06-22 22:57 GMT+02:00 Matt . :
> OK,
>
> I'm on the go here but I have some issue.
>
> When I install the replica server I get this error on the new replica:
>
> ipa : CRITICAL CA DS schema check failed. Make sure the PKI
> service on the remote master is operational.
>
>
> When I restart IPA on the old master I get this:
>
> PKI-IPA...[22/Jun/2015:22:50:36 +0200] attr_syntax_create - Error:
> the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with
> the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
> [22/Jun/2015:22:50:36 +0200] attr_syntax_create - Error: the SUBSTR
> matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with
> the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc]
>[  OK  ]
>
> So the error on the replica is not that strange, but how to fix this
> on the master ?
>
> Matt
>
> 2015-06-22 15:59 GMT+02:00 Hendrik Frenzel :
>> Am 22.06.2015 12:10, schrieb Matt .:
>>>
>>> Hi Guys,
>>
>>
>> Hi Matt,
>>
>>> I found some good information about migrating from 3.3 to 4.x using
>>> replica's.
>>>
>>> It's not 100% clear what I can do on a CentOS 6.6 install with 3.0 as
>>> CentOS doesn't provide 3.3.
>>
>>
>> Could you please share an URL or something?
>>
>> Currently I'm here:
>>
>>  * ipa-6 - CentOS 6.6:
>>ipa-admintools-3.0.0-42.el6.centos.x86_64
>>ipa-client-3.0.0-42.el6.centos.x86_64
>>ipa-pki-ca-theme-9.0.3-7.el6.noarch
>>ipa-pki-common-theme-9.0.3-7.el6.noarch
>>ipa-python-3.0.0-42.el6.centos.x86_64
>>ipa-server-3.0.0-42.el6.centos.x86_64
>>ipa-server-selinux-3.0.0-42.el6.centos.x86_64
>>sssd-ipa-1.11.6-30.el6_6.4.x86_64
>>pki-ca-9.0.3-38.el6_6.noarch
>>
>>  * ipa-7 - CentOS 7.1 (fresh/minimal installation with ipa-server, bind,
>> bind-dyndb-ldap):
>>ipa-admintools-4.1.0-18.el7.centos.3.x86_64
>>ipa-client-4.1.0-18.el7.centos.3.x86_64
>>ipa-python-4.1.0-18.el7.centos.3.x86_64
>>ipa-server-4.1.0-18.el7.centos.3.x86_64
>>sssd-ipa-1.12.2-58.el7_1.6.x86_64
>>pki-ca-10.1.2-7.el7.noarch
>>
>>   -1. Update schema
>>   ipa-7# scp /usr/share/ipa/copy-schema-to-ca.py root@ipa-6:
>>   ipa-6# python copy-schema-to-ca.py
>>
>>0. clean up old/stale replication aggreements
>>   ipa-replica-manage del --force ipa-6.example.com
>>   ipa-csreplica-manage del --force ipa-6.example.com
>>
>>1. prepare replication on ipa-6 for ipa-7
>>   ipa-replica-prepare ipa-7.example.com
>>
>>2. add |^/ca/ee/ca/profileSubmit to the EE LocationMatch in
>> /etc/httpd/conf.d/ipa-pki-proxy.conf on ipa-6 (s.
>> https://www.redhat.com/archives/freeipa-users/2015-May/msg00283.html)
>>   - > "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL">
>>   + > "^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL|^/ca/ee/ca/profileSubmit">
>>
>>3. slow down the network a bit
>>   (don't know how effective it is, as we already got 1GBit, but without
>> it, a timing bug in 389-ds-base is triggered - s.
>> https://www.redhat.com/archives/freeipa-users/2015-May/msg00283.html)
>>   tc qdisc add dev eth0 root handle 1: tbf rate 1000mbit latency 1ms
>> burst 1540
>>
>>4. install replication (without CA for the moment)
>>   ipa-replica-install /var/lib/ipa/replica-info-ipa-7.example.com.gpg
>> --setup-dns --mkhomedir --no-forwarders
>>
>> Up to now, everything works, but we need the CA too:
>>
>>5. install ca
>>   ipa-ca-install /var/lib/ipa/replica-info-ipa-7.example.com.gpg
>>
>> But this won't work and I don't have a clue how to fix/proceed from here.
>>
>>   # ipa-7: /var/log/ipareplica-ca-install.log
>>   ipa : DEBUGstderr=pkispawn: WARNING  ... unable to
>> validate security domain user/password through REST interface. Interface not
>> available
>>   pkispawn: ERROR... Exception from Java Configuration Servlet:
>> Error while updating security domain: java.io.IOException: 2
>>
>>   ipa : CRITICAL failed to configure ca instance Command
>> ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmppByBPz'' returned non-zero
>> exit status 1
>>   ipa : DEBUGTraceback (most recent call last):
>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 382, in start_creation
>>   run_step(full_msg, method)
>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 372, in run_step
>>   method()
>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
>> line 673, in __spawn_instance
>>   raise RuntimeError('Co

[Freeipa-users] Integrating samba 4 to AD for authentication with an IPA enabled client.

[Steven Jones]

Hi,

Is this possible?I am trying to find some docs to do this but they point at 
sssd and/or kerberos.  But looking at RHEL7.1 / samba 4 it looks to me that 
with an IPA enabled client sssd, kerberos and ldap files/configuration are 
committed to IPA's use so cannot be altered?


regards

Steven

-- 
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] Crazy Cert problem?

[Janelle]

On 6/22/15 7:37 AM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 2:00 PM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:21 AM, Rob Crittenden wrote:

Janelle wrote:

On 6/17/15 6:14 AM, Rob Crittenden wrote:

Janelle wrote:

Hi,

Had a server - named ipa001.example.com -- it was a replica. It
died. It
was re-installed. However, prior to the re-install it was 
saying the

wonderful:

TLS error -8172:Peer's certificate issuer has been marked as not
trusted
by the user.

It was rebuilt - new OS and doing a brand new ipa-server-install
(NOT a
replica or trying to join it back in to the existing ring of
servers)
and at the end of the ipa-server-install - it gives:

Done.
Restarting the directory server
Restarting the KDC
Restarting the certificate server
Restarting the web server
Unable to set admin password Command ''/usr/bin/ldappasswd' '-h'
'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y'
'/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs'
'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned
non-zero
exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command 
''/usr/sbin/ipa-client-install'

'--on-master' '--unattended' '--domain' 'example.com' '--server'
'ipa001.example.com' '--realm' 'example.com' '--hostname'
'ipa001.example.com'' returned non-zero exit status 1

and checking /var/log/ipaclient-install.log - the exact same TLS
error

But this is a brand new system, with brand new OS and the install
was
ipa-server-install to install a clean server.

I don't understand how this is happening. There is no "peer" to
be not
trusted?


What version of IPA and distro? (I don't think that probably has
anything to do with it, just curious in case it does eventually
matter).

What does /etc/openldap/ldap.conf look like? Normally it should 
have

TLS_CACERT /etc/ipa/ca.crt

Any chance you can share the server and client install logs?

rob

4.1.4 = IPA
CentOS 7.1

Oooh... Found something:  /etc/openldap/ldap.conf:

TLS_CACERTDIR/etc/openldap/certs

Going to investigate.
~J



That should be fine assuming there aren't any certs in there (and 
on a

brand new system I'd think you'd have empty NSS databases).

rob

So this gets interesting now...

Say you have 6 IPA servers, named ipa001-ipa006.example.com -- all
working fine.
Something happens to 002. It dies. You "ipa-replica-manage del --clean
--force ipa002" to get rid of it.

A period of time, say a month, goes by. You have lost a couple of 
other

replicas for whatever reason, say 3 and 6. You decide you want to
rebuild. You start with 002 - leaving the others up and running 
because

you have users working. You firewall off 002 why you rebuild it.

You reinstall OS, reinstall FreeIPA. But no matter what, when you 
start
to configure IPA it comes up with the error of being untrusted. 
Now, you

try the same thing on 003 and 006. SAME problem.

For fun - you shutdown 005 and uninstall freeipa --unattended and then
try to re-install it. Guess what - no issues.

Is this somehow related to:
Same domain and realm names floating around the net - so is it 
querying

for a name somehow and one of the "still running" servers is saying -
"NO NO NO -- that CERT is revoked!!!" - even though it never tries to
connect to that server.

Or am I just thinking far too outside the box?  And this is exactly 
what

has happened. Rebuilding one of the servers that was never REMOVED is
working just fine.


You just jumped to a completely different scenario: from a fresh
standalone install to a replica install. We should probably pick one
and solve it.

I think the leap you're making is that the issue is that it notices
some previous cert. A revoked service cert wouldn't have any effect as
those service certs aren't in use.

It very well could be finding the "wrong" realm based on DNS SRV
records. The logs should show you what the client discovered. Things
happen in multiple steps so perhaps there is a disconnect where the
right server is used in some, but not all, cases.

rob


ALL the problems were all related. Even after building brand new
servers, the problem persisted and then started cropping up with client
installs.

The solution traced to bad NSS packages. A simple "yum downgrade nss
nss-sysinit nss-tools" solved it.. Something is up with the 3.18 verion
and downgrading to 3.16 seems to have resolved. Should have known it
would all be related to an upgrade.  Sometimes a slightly older version
is best.

~Janelle


Can you open a bugzilla about this?

rob

This looks like the fix - besides downgrading:

https://bugzilla.mozilla.org/show_bug.cgi?id=1132941


--
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] Question for AD trust and Webservices

[Alexander Bokovoy]

On Tue, 23 Jun 2015, Dmitri Pal wrote:

On 06/17/2015 09:56 AM, Alexander Bokovoy wrote:

On Wed, 17 Jun 2015, Henry Hofmann wrote:
Ok, how can I configure the map of source attributes (mail or any 
other) to compat tree?

Go back in archives in this list and read discussions about "Single mail
deployment in an FreeIPA-WindowsAD scenario". TLDR; not possible in the
compat tree as of right now.


Do we have a ticket for this?

No and I don't think it will be possible. slapi-nis is read-only view,
it needs to get these attributes from somewhere. Storing values for
specialized schema in ID overrides is probably going to be too much --
how these source attributes to be managed? In the case of 'single mail'
it would need to be Kolab applications which would need to update such
attributes, how Kolab would do that?

Enabling slapi-nis to be writeable is going to break a lot and in
general would not be possible.
--
/ Alexander Bokovoy

--
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] Question for AD trust and Webservices

[Dmitri Pal]

On 06/17/2015 09:56 AM, Alexander Bokovoy wrote:

On Wed, 17 Jun 2015, Henry Hofmann wrote:
Ok, how can I configure the map of source attributes (mail or any 
other) to compat tree?

Go back in archives in this list and read discussions about "Single mail
deployment in an FreeIPA-WindowsAD scenario". TLDR; not possible in the
compat tree as of right now.


Do we have a ticket for this?

--
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.

--
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] ruv issue?

[Mark Reynolds]

On 06/23/2015 01:44 PM, Marc Wiatrowski wrote:

So I have 3 servers, spider01a, spider01b, and spider01o

[root@spider01a]$ ipa-replica-manage list-ruv
Directory Manager password:

spider01a.iglass.net:389 : 12
spider01o.iglass.net:389 : 13
spider01b.iglass.net:389 : 7
spider01a.iglass.net:389 : 5

[root@spider01b]$ ipa-replica-manage list-ruv
Directory Manager password:

spider01b.iglass.net:389 : 7
spider01a.iglass.net:389 : 12
spider01a.iglass.net:389 : 5
spider01o.iglass.net:389 : 13

[root@spider01o]$ ipa-replica-manage list-ruv
Directory Manager password:

spider01o.iglass.net:389 : 13
spider01a.iglass.net:389 : 12
spider01b.iglass.net:389 : 7
spider01a.iglass.net:389 : 5

I'm not seeing any issues, but there is only one spider01a (which was 
replaced at some point) Is the duplicate spider01a a problem?  This a 
case for using clean-ruv?

Yes it is.

You need to know which replica id (5 or 12) is the old/invalid rid. You 
can look at /etc/dirsrv/slapd-INSTANCE/dse.ldif on spider01a, and look 
for nsDS5ReplicaId.  The value you find is your current rid, so you can 
clean the other one.  However it is possible that both 5 and 12 are 
valid.  Each backend can have its own replication config - so once again 
look for all the nsDS5ReplicaId attributes to verify if its being used 
or not.


Mark

If so, is there a way tell which one to run it on?

thanks,
Marc





-- 
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] ruv issue?

[Marc Wiatrowski]

So I have 3 servers, spider01a, spider01b, and spider01o

[root@spider01a]$ ipa-replica-manage list-ruv
Directory Manager password:

spider01a.iglass.net:389: 12
spider01o.iglass.net:389: 13
spider01b.iglass.net:389: 7
spider01a.iglass.net:389: 5

[root@spider01b]$ ipa-replica-manage list-ruv
Directory Manager password:

spider01b.iglass.net:389: 7
spider01a.iglass.net:389: 12
spider01a.iglass.net:389: 5
spider01o.iglass.net:389: 13

[root@spider01o]$ ipa-replica-manage list-ruv
Directory Manager password:

spider01o.iglass.net:389: 13
spider01a.iglass.net:389: 12
spider01b.iglass.net:389: 7
spider01a.iglass.net:389: 5

I'm not seeing any issues, but there is only one spider01a (which was
replaced at some point) Is the duplicate spider01a a problem?  This a case
for using clean-ruv?  If so, is there a way tell which one to run it on?

thanks,
Marc
-- 
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] Announcing bind-dyndb-ldap version 8.0

[Petr Spacek]

The FreeIPA team is proud to announce bind-dyndb-ldap version 8.0.

It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/

The new version has also been built for Fedora 23+ (rawhide).

This version is also available from FreeIPA 4.2 COPR repo:
https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.2/

Latest news:
8.0

[1] Unknown record types can be stored in LDAP using generic syntax
(RFC 3597). LDAP schema was extended for this purpose with the
UnknownRecord attribute.
https://fedorahosted.org/bind-dyndb-ldap/ticket/157

[2] PTR record synchronization was improved.
- New PTR records now inherit the TTL value from the respective A/
  records.
- SERVFAIL error is no longer returned to clients if A/ record update
  succeeded but PTR record synchronization failed because of
  misconfiguration. Such errors are only logged.
- PTR record synchronization was reworked to reduce the probability
  of race condition occurrences.
https://fedorahosted.org/bind-dyndb-ldap/ticket/155

[3] LDAP rename (MODRDN) for DNS records is now supported.
Renaming of whole DNS zones is not supported and will lead to errors.
https://fedorahosted.org/bind-dyndb-ldap/ticket/123

[4] Data changed in LDAP while connection to server was down are now refreshed
properly.
https://fedorahosted.org/bind-dyndb-ldap/ticket/128

[5] Crash caused by object class and DN format mismatch were fixed.
https://fedorahosted.org/bind-dyndb-ldap/ticket/148

[6] Compatibility with BIND 9.9.4 was improved.

[7] Documentation and schema were fixed and improved. The doc/schema.ldif file
is now properly formatted as LDIF and contains instructions
for OpenLDAP and 389 DS.

7.0

[1] Support for BIND 9.10 was added.
https://fedorahosted.org/bind-dyndb-ldap/ticket/139


== Upgrading ==
A server can be upgraded by installing updated RPM. BIND has to be restarted
manually after the RPM installation.

Downgrading back to any 7.x version is supported if user is not relying on
support for unknown attribute types or LDAP MODRDN operation.


== Feedback ==
Please provide comments, report bugs and send any other feedback via the
freeipa-users mailing list:
http://www.redhat.com/mailman/listinfo/freeipa-users

-- 
Petr^2 Spacek

-- 
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] search filter with non-existent attribute

[Petr Spacek]

On 23.6.2015 15:41, Tamas Papp wrote:
> hi,
> 
> This works:
> 
> $ ldapsearch -LLL -x -b cn=users,cn=accounts,dc=cxn
> "(|(mail=admin*)(uid=admin))" uid
> dn: uid=admin,cn=users,cn=accounts,dc=cxn
> uid: admin
> 
> 
> This not:
> 
> $ ldapsearch -LLL -x -b cn=users,cn=accounts,dc=cxn
> "(|(aaa=admin*)(uid=admin))" uid
> $
> 
> 
> If there is search filter with non-existent attribute there is no result.
> Is that intentional? In CentOS 6.6 it worked just fine.

As far as I can tell this happens when the search is attempting to evaluate
the filter and access to that attribute is denied by ACI. In newer version of
FreeIPA everything is closed by default and access is allowed only to certain
subset of attributes.

What version of FreeIPA do you have? What version of 389-ds-base package do
you have?

$ rpm -q 389-ds-base freeipa-server ipa-server

-- 
Petr^2 Spacek

-- 
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] search filter with non-existent attribute

[Tamas Papp]

hi,

This works:

$ ldapsearch -LLL -x -b cn=users,cn=accounts,dc=cxn 
"(|(mail=admin*)(uid=admin))" uid

dn: uid=admin,cn=users,cn=accounts,dc=cxn
uid: admin


This not:

$ ldapsearch -LLL -x -b cn=users,cn=accounts,dc=cxn 
"(|(aaa=admin*)(uid=admin))" uid

$


If there is search filter with non-existent attribute there is no result.
Is that intentional? In CentOS 6.6 it worked just fine.


10x
tamas

--
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] Antwort: Re: Antwort: clean-run doesn't work

[Alexander Frolushkin]

Unfortunately I can't really say what exactly it was -  all of this dups 
already gone by almost every IPA replica's re-initializing.
But it definitely was related to heavy load due to debug mode. The system 
itself was working as usual - a lot of this domain enrolled servers served 
users logins and so on, nothing special. Heavy loaded IPA servers while they 
was in debug mode failed to authenticate users, so sssd on clients have to use 
secondary servers.

Our IPA/IdM system currently in limited production state, so we cannot repeat 
this conditions to test what exactly happened.
I'm sorry for being useless now to explore the problem :(

WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764

From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Tuesday, June 23, 2015 2:51 PM
To: Alexander Frolushkin (SIB)
Cc: Tamas Papp; 'Christoph Kaminski'; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Antwort: Re: Antwort: clean-run doesn't work

Hi Alexander,

This is mainly replication logging. Having many instances will increase the 
amount of logging especially if you have updates.
To create duplicate you are doing ADD in parallele of the same dn on differents 
servers. Do you what creates this ADD load ?
Can you see MODs/DELs ?

thanks
thierry
On 06/23/2015 06:01 AM, Alexander Frolushkin wrote:
Hello.
We have 19 RHEL 7.1 IPA (ipa-server-4.1.0-18.el7_1.3.x86_64) servers.
Debug level was changed this way on 4 of them:
dn: cn=config
changetype: modify
replace: nsslapd-errorlog-level
nsslapd-errorlog-level:24576
-
replace: nsslapd-accesslog-level
nsslapd-accesslog-level:256
EOF

After this, IO was increased significally.
Two of servers hangs after some time, a lot of dups appears on most IPA servers 
in domain.


WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764

From: thierry bordaz [mailto:tbor...@redhat.com]
Sent: Monday, June 22, 2015 6:21 PM
To: Tamas Papp
Cc: Alexander Frolushkin (SIB); 'Christoph Kaminski'; 
freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Antwort: Re: Antwort: clean-run doesn't work

On 06/22/2015 11:50 AM, Tamas Papp wrote:
Fascinating.

Can you Red Hat guys reproduce this in you test environment?

Most of my tests are on RHEV with RHEL 7.1, I have not seen a crash of DS.
About the test case, you installed a server+replicas (version ?), then turn on 
errorlog-level (do you remember what level).
That would slow down the DS instance and fill errors log.
Then you hit extremely frequently a crash. Do you remember what kind of the 
load search/mod/add/del ?

thanks
thierry



Thanks,
tamas
On 06/22/2015 11:42 AM, Alexander Frolushkin wrote:
Hello everyone.
I can confirm this on VMWare, recently we have the similar issue when enabled 
dirsrv debug on 4 of our 19 IPA servers :(

WBR,
Alexander Frolushkin
Cell +79232508764
Work +79232507764

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Christoph Kaminski
Sent: Monday, June 22, 2015 2:50 PM
To: Tamas Papp
Cc: freeipa-users@redhat.com
Subject: [Freeipa-users] Antwort: Re: Antwort: clean-run doesn't work

>
> In my particular case I'm interested, whether it can crash servers.
> Does it for you? I don't see it in that thread.
>
> tamas

yes... we has had a really often a crash on virtual machines installations. On 
bare metal we had 2-3x a crash.

That was the reason for us to destroy all IPA VM's. There seems to be an IO 
issue on VM's with IPA (rhev virtualisation here). You can see it extremly if 
you turn the debug level higher.

Greetz



Информация в этом сообщении предназначена исключительно для конкретных лиц, 
которым она адресована. В сообщении может содержаться конфиденциальная 
информация, которая не может быть раскрыта или использована кем-либо, кроме 
адресатов. Если вы не адресат этого сообщения, то использование, переадресация, 
копирование или распространение содержания сообщения или его части незаконно и 
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно 
сообщите отправителю об этом и удалите со всем содержимым само сообщение и 
любые возможные его копии и приложения.

The information contained in this communication is intended solely for the use 
of the individual or entity to whom it is addressed and others authorized to 
receive it. It may contain confidential or legally privileged information. The 
contents may not be disclosed or used by anyone other than the addressee. If 
you are not the intended recipient(s), any use, disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. If you have received this communication in 
error please notify us immediately by responding to this email and then delete 
the e-mail and all attachments and any copies thereof.

(c)20mf50








Инфор

Re: [Freeipa-users] Antwort: Re: Antwort: clean-run doesn't work

[thierry bordaz]

Hi Alexander,

This is mainly replication logging. Having many instances will increase 
the amount of logging especially if you have updates.
To create duplicate you are doing ADD in parallele of the same dn on 
differents servers. Do you what creates this ADD load ?

Can you see MODs/DELs ?

thanks
thierry
On 06/23/2015 06:01 AM, Alexander Frolushkin wrote:


Hello.

We have 19 RHEL 7.1 IPA (ipa-server-4.1.0-18.el7_1.3.x86_64) servers.

Debug level was changed this way on 4 of them:

dn: cn=config

changetype: modify

replace: nsslapd-errorlog-level

nsslapd-errorlog-level:24576

-

replace: nsslapd-accesslog-level

nsslapd-accesslog-level:256

EOF

After this, IO was increased significally.

Two of servers hangs after some time, a lot of dups appears on most 
IPA servers in domain.


WBR,

Alexander Frolushkin

Cell +79232508764

Work +79232507764

*From:*thierry bordaz [mailto:tbor...@redhat.com]
*Sent:* Monday, June 22, 2015 6:21 PM
*To:* Tamas Papp
*Cc:* Alexander Frolushkin (SIB); 'Christoph Kaminski'; 
freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] Antwort: Re: Antwort: clean-run doesn't 
work


On 06/22/2015 11:50 AM, Tamas Papp wrote:

Fascinating.

Can you Red Hat guys reproduce this in you test environment?


Most of my tests are on RHEV with RHEL 7.1, I have not seen a crash of DS.
About the test case, you installed a server+replicas (version ?), then 
turn on errorlog-level (do you remember what level).

That would slow down the DS instance and fill errors log.
Then you hit extremely frequently a crash. Do you remember what kind 
of the load search/mod/add/del ?


thanks
thierry


Thanks,
tamas

On 06/22/2015 11:42 AM, Alexander Frolushkin wrote:

Hello everyone.

I can confirm this on VMWare, recently we have the similar issue
when enabled dirsrv debug on 4 of our 19 IPA servers L

WBR,

Alexander Frolushkin

Cell +79232508764

Work +79232507764

*From:*freeipa-users-boun...@redhat.com

[mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Christoph
Kaminski
*Sent:* Monday, June 22, 2015 2:50 PM
*To:* Tamas Papp
*Cc:* freeipa-users@redhat.com 
*Subject:* [Freeipa-users] Antwort: Re: Antwort: clean-run doesn't
work

>
> In my particular case I'm interested, whether it can crash servers.
> Does it for you? I don't see it in that thread.
>
> tamas

yes... we has had a really often a crash on virtual machines
installations. On bare metal we had 2-3x a crash.

That was the reason for us to destroy all IPA VM's. There seems to
be an IO issue on VM's with IPA (rhev virtualisation here). You
can see it extremly if you turn the debug level higher.

Greetz




Информация в этом сообщении предназначена исключительно для
конкретных лиц, которым она адресована. В сообщении может
содержаться конфиденциальная информация, которая не может быть
раскрыта или использована кем-либо, кроме адресатов. Если вы не
адресат этого сообщения, то использование, переадресация,
копирование или распространение содержания сообщения или его части
незаконно и запрещено. Если Вы получили это сообщение ошибочно,
пожалуйста, незамедлительно сообщите отправителю об этом и удалите
со всем содержимым само сообщение и любые возможные его копии и
приложения.

The information contained in this communication is intended solely
for the use of the individual or entity to whom it is addressed
and others authorized to receive it. It may contain confidential
or legally privileged information. The contents may not be
disclosed or used by anyone other than the addressee. If you are
not the intended recipient(s), any use, disclosure, copying,
distribution or any action taken or omitted to be taken in
reliance on it is prohibited and may be unlawful. If you have
received this communication in error please notify us immediately
by responding to this email and then delete the e-mail and all
attachments and any copies thereof.

(c)20mf50







Информация в этом сообщении предназначена исключительно для конкретных 
лиц, которым она адресована. В сообщении может содержаться 
конфиденциальная информация, которая не может быть раскрыта или 
использована кем-либо, кроме адресатов. Если вы не адресат этого 
сообщения, то использование, переадресация, копирование или 
распространение содержания сообщения или его части незаконно и 
запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, 
незамедлительно сообщите отправителю об этом и удалите со всем 
содержимым само сообщение и любые возможные его копии и приложения.


The information contained in this communication is intended solely for 
the use of the individual o

Re: [Freeipa-users] invalid 'permission': cannot add permission "System: Read HBAC Rules" with bindtype "all" to a privilege

[Petr Vobornik]

On 06/22/2015 10:09 PM, Rob Crittenden wrote:

Nathan Peters wrote:



-Original Message- From: Rob Crittenden
Sent: Saturday, June 20, 2015 1:17 PM
To: Nathan Peters
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] invalid 'permission': cannot add permission
"System: Read HBAC Rules" with bindtype "all" to a privilege

Nathan Peters wrote:



-Original Message- From: Rob Crittenden
Sent: Friday, June 19, 2015 3:38 PM
To: nat...@nathanpeters.com
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] invalid 'permission': cannot add permission
"System: Read HBAC Rules" with bindtype "all" to a privilege

nat...@nathanpeters.com wrote:

nat...@nathanpeters.com wrote:

FreeIPA server 4.1.3 on CentOS 7

I am trying to create a set of privileges or roles that will allow
me to
create a user who has read-only access to as much of the FreeIPA
web UI
as
possible.  Basically my manager want the type of view into FreeIPA
that
they have in AD using the 'AD Users and Computers program).

I note that there are quite a few read permission in the permissions
list.
   I tried creating a new privilege called Read Only Administrator
and
giving them all the permission that have read only in the name.

For some reason I can add all other system and full access
permissions
but
when I try to add a read only permission I get the following error :
invalid 'permission': cannot add permission "System: Read HBAC Rules"
with
bindtype "all" to a privilege

This applies not just the HBAC rule, but anything that has Read in
the
name.

How do I create a read only user without getting this error message?


You can't add a rule with bindtype all because this bindtype already
allows all authenticated users the rights granted by the rule, in this
case read access.

rob




That doesn't sound right.  When I login to FreeIPA web ui with a user
who
is not part of any group, the only thing he can do is browse other
users
and update his own password and SSH key.  He does not get the HBAC menu
and definitely cannot browse HBAC rules.


The UI handles those permissions differently.

$ kinit someuser
$ ldapsearch -Y GSSAPI -b cn=hbac,dc=example,dc=com



Also, If I do this step backward and go directly to the RBAC ->
Permissions menu and choose a permission and edit it, I can add it to a
privilege, but if I go to the privilege and try to add the
permission it
fails.  This makes zero sense.

I can post screenshots if that helps.



This is a bug. There is a function not available on the command line,
permission_add_member, which incorrectly allows this. I opened
https://fedorahosted.org/freeipa/ticket/5075

Regardless of whether it is added or not, it is a no-op because the
whole idea of permissions is to grant access via groups and there is no
group in this permission. It allows all authenticated users.

rob

What do you mean by it is a no-op?

Here is what I did that worked:

1)Create privilege called "Read only privilege"

2)Go to each permission individually that has the world "Read" in it and
add them to the "read only privilege" privilege one at a time.  There
was about 65 of them.  This is fine because we are not apply this to
users, only apply the permissions to the privilege.

3)Next, go back to the read-only privilege and add some group that
contains users.

4)Login to the webui as a user that is in the group that was added to
the privilege and now you can see all menu options just like an admin,
but everything is read only and any attempt to make changes results in a
message that you don't have permission to make that change.  This is
currently working exactly as I expect it to once I set it up the long
way.

Result : Member can now browse the entire web ui and see everything,
hosts, users, rbac rules, hbac rules, groups etc but in read only mode
as expected.

I'm talking only about the issue where a permission with a bindrule of
all cannot be added to a privilege. The fact that it can be added in
the UI is a bug.

It is the data in LDAP we really care about and a permission with a
bindrule of all grants all authenticated users read access to that
data, regardless of what you might or might not see in the UI.

I'm not entirely sure how Petr does that though I always thought it
was through LDAP effective rights which in effect should grant all
users HBAC read access, so perhaps he determines it based on other
things as well.

rob


So what is the correct way to grant full read-only permissions in the
web UI?  The audience for this viewing is managers and they are non
technical and have no desire to login to an SSH shell and try to view
the data they need using the cli.

They have seen me working in the web UI and really like how easy it is
to browse the interface.

Is there any proper way to do this?  Is it possible at all without
invoking that bug that I invoked to make it happen?


That's a question for Petr. I don't know how the UI determines which
tabs to make visible. I thought it was based on the effective 

Re: [Freeipa-users] Very Odd Fedora 21 Auth Issue (Server: IPA 4.1.0)

[Sumit Bose]

On Tue, Jun 23, 2015 at 05:24:32PM +1000, craig.red...@shakenautomotive.com.au 
wrote:
> Hi, 
> This is one odd issue?!
> 
> Red Hat Enterprise Linux 7.1
> 
> #Server Side
> Red Hat Enterprise Linux Server release 7.1 (Maipo)
> ipa-server-4.1.0-18.el7_1.3.x86_64
> 
> #Client side
> Fedora release 21 (Twenty One)
> * freeipa-client-4.1.4-1.fc21.x86_64
> * sssd-client-1.12.4-3.fc21.x86_64
> 
> 
> Issue:
> User cannot login to their PC 
> 
> Error: /var/log/secure
> Jun 23 17:08:48 johnpc sshd[3591]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost  user=john
> Jun 23 17:08:48 johnpc sshd[3591]: pam_sss(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=john
> Jun 23 17:08:48 johnpc sshd[3591]: pam_sss(sshd:auth): received for user
> john: 7 (Authentication failure)
> 
> However:
> 1. Kerberous works;
> kinit john 
> john@johnpc /etc/pam.d> klist
> Ticket cache: KEYRING:persistent:365:365
> Default principal: j...@example.exampleaus.com.au
> 
> Valid starting ExpiresService principal
> 23/06/15 16:49:30  24/06/15 16:49:28
> krbtgt/example.exampleaus.com...@example.exampleaus.com.au
> 
> 2. LDAP works;
> john@johnpc ~> getent passwd john
> john:x:365:132::/home/john:/bin/bash
> 
> 3. ssh to IPA server works with a password (so not relying on the kerberous
> ticket);
> john@erio ~> ssh john@sysvm-ipa1
> john@sysvm-ipa1's password: 
> Last login: Tue Jun 23 16:50:02 2015 from johnpc.example.exampleaus.com.au
> 
> 
> Any advice would be greatly appreciated? 

I think we need sssd logs here, please see
https://fedorahosted.org/sssd/wiki/Troubleshooting for details. We need
at least logs for the PAM responder ([pam] section in sssd.conf) and
the backend ([domain/...] section in sssd.conf).

bye,
Sumit

> 
> Regards,
> 
> Craig
> 
> -- 
> 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] Very Odd Fedora 21 Auth Issue (Server: IPA 4.1.0)

[craig . redhat]

Hi, 
This is one odd issue?!

Red Hat Enterprise Linux 7.1

#Server Side
Red Hat Enterprise Linux Server release 7.1 (Maipo)
ipa-server-4.1.0-18.el7_1.3.x86_64

#Client side
Fedora release 21 (Twenty One)
* freeipa-client-4.1.4-1.fc21.x86_64
* sssd-client-1.12.4-3.fc21.x86_64


Issue:
User cannot login to their PC 

Error: /var/log/secure
Jun 23 17:08:48 johnpc sshd[3591]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost  user=john
Jun 23 17:08:48 johnpc sshd[3591]: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=john
Jun 23 17:08:48 johnpc sshd[3591]: pam_sss(sshd:auth): received for user
john: 7 (Authentication failure)

However:
1. Kerberous works;
kinit john 
john@johnpc /etc/pam.d> klist
Ticket cache: KEYRING:persistent:365:365
Default principal: j...@example.exampleaus.com.au

Valid starting ExpiresService principal
23/06/15 16:49:30  24/06/15 16:49:28
krbtgt/example.exampleaus.com...@example.exampleaus.com.au

2. LDAP works;
john@johnpc ~> getent passwd john
john:x:365:132::/home/john:/bin/bash

3. ssh to IPA server works with a password (so not relying on the kerberous
ticket);
john@erio ~> ssh john@sysvm-ipa1
john@sysvm-ipa1's password: 
Last login: Tue Jun 23 16:50:02 2015 from johnpc.example.exampleaus.com.au


Any advice would be greatly appreciated? 

Regards,

Craig

-- 
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