date:20141023


I already deployed FreeIPA 4.1 on Fedora 21 server alpha-release.
Everything is good as far as FreeIPA server operation is concerned.


23-Oct-14 01:06, William Graboyes пишет:

3) am I insane for wanting to introduce FC21 into my environment?


--
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] No result when trying to integrate a FreeBSD client with the FreeIPA server

On (23/10/14 11:27), Outback Dingo wrote:
On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale ftwee...@redhat.com
wrote:

 On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote:
  On (22/10/14 17:10), Fraser Tweedale wrote:
  Further to my earlier email, I have written a blog post about all
  these matters, with a particular focus on the custom package repo.
  
  I will update it tomorrow with a bit more about the package
  flavours topic.  For now, all the details for enabling and using
  the custom repo are in the post.  Check it out and let me know if
  you spot any issues.
  
  
 http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/
  
  The disadvantage of this approach is that users need to rely on updating
  of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA
 
  In my opinion, it's better to write howto (script) which will configure
 all
  necessary ports/files and portmaster will take care of updating ports.
  https://www.freebsd.org/doc/handbook/ports-using.html#portmaster
 
  LS

 Each has its advantages and disadvantages; people can choose what
 works for them.  Hopefully - not too far in the future - people
 won't have to choose, when binary package flavours are
 implemented.  When that happens, a small effort will be needed to
 define the FreeIPA flavour and ensure it gets included in the
 official package repos.

Fraser you missed one main point of this thread. The most problematic was
to *configure* all files and not install sssd. I don't want to say that
installing is super easy, but configuration is much more complicated.


Actually I would be inclined to assist with a ports build, so it could be
done correctly from the ports tree
and work towards having it adopted into mainline.

+1

LS

-- 
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] No result when trying to integrate a FreeBSD client with the FreeIPA server

2014-10-23 Thread Орхан Касумов

 +1.
And even if talking about installation of the necessary software and not about 
the configuration, then why this?

 The commands to enable the custom repository and install the required 
packages on a FreeBSD host appear below.
Note that these are  Bourne  shell commands; this script will not work in the 
FreeBSD default shell  csh . 

After having baked ONE SET OF DEFAULTS into a custom package (to make our lives 
easier), you leave readers to mess with ANOTHER SET OF DEFAULTS, i.e. to change 
FreeBSD's shells?
Aren't there some discrepancies? It may be simple / useful / interesting to 
change shells, but why not make a self-sufficient article?
Please update your article to provide a full picture of what a user should do 
to install all necessary software, and also which parts should be installed 
from your repo, and which parts should be installed from ports (+ the correct 
order).
You've already done a lot of work, but with this refinement your help will be 
even more valuable.
I'm not asking for myself personally (I've already accomplished all necessary 
tasks) - just IMHO everyone writing instructions, tutorials and HowTos for the 
*nix world should stick to the rule: articles should be self-sufficient.
I.e. if they rely on techniques not detailed in them, they should at least 
include links to other WORKING articles to ensure that a reader will be able to 
COMPLETE a task.
Thanks for your contribution, Fraser.


Thu, 23 Oct 2014 09:58:33 +0200 от Lukas Slebodnik lsleb...@redhat.com:
On (23/10/14 11:27), Outback Dingo wrote:
On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale  ftwee...@redhat.com 
wrote:

 On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote:
  On (22/10/14 17:10), Fraser Tweedale wrote:
  Further to my earlier email, I have written a blog post about all
  these matters, with a particular focus on the custom package repo.
  
  I will update it tomorrow with a bit more about the package
  flavours topic.  For now, all the details for enabling and using
  the custom repo are in the post.  Check it out and let me know if
  you spot any issues.
  
  
  
 http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/
  
  The disadvantage of this approach is that users need to rely on updating
  of non standard repo.  https://frase.id.au/pkg/${ABI}_FreeIPA
 
  In my opinion, it's better to write howto (script) which will configure
 all
  necessary ports/files and portmaster will take care of updating ports.
   https://www.freebsd.org/doc/handbook/ports-using.html#portmaster
 
  LS

 Each has its advantages and disadvantages; people can choose what
 works for them.  Hopefully - not too far in the future - people
 won't have to choose, when binary package flavours are
 implemented.  When that happens, a small effort will be needed to
 define the FreeIPA flavour and ensure it gets included in the
 official package repos.

Fraser you missed one main point of this thread. The most problematic was
to *configure* all files and not install sssd. I don't want to say that
installing is super easy, but configuration is much more complicated.


Actually I would be inclined to assist with a ports build, so it could be
done correctly from the ports tree
and work towards having it adopted into mainline.

+1

LS

-- 
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] Announcing FreeIPA 4.1.0

2014-10-23 Thread Petr Vobornik


The FreeIPA team is proud to announce FreeIPA v4.1.0!

It can be downloaded from http://www.freeipa.org/page/Downloads. The 
builds will be available for Fedora 21. Builds for Fedora 20 are 
available in the official COPR repository 
[https://copr.fedoraproject.org/coprs/mkosek/freeipa/].


== Highlights in 4.1 ==
=== Enhancements ===
* New concept of 'ID Views' allowing FreeIPA administrator to define or 
override POSIX attributes for users/groups coming from trusted domains. 
Such users then do not need to have POSIX attributes defined in the 
Active Directory to authenticate to FreeIPA clients. It also allows to 
assign particular view to selected hosts or hostgroups, thus allowing 
having a user / group with different POSIX attributes on different 
hosts. Per-host overrides should be used with extreme care! 
[http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust]
* New tool ipa-cacert-manage to manually renew or change FreeIPA PKI CA 
certificate [http://www.freeipa.org/page/V4/CA_certificate_renewal]

* DNSSEC Support
* OTP authentication plugin now prevents multiple usage of token codes 
on a single FreeIPA server
* DNS interface now supports adding DNS root zone (.) allowing admin 
to for example centrally override DNS root hints.
* DNS zone adding interface was simplified - name server and it's IP 
address is no longer required. The list of authoritative name servers 
are read from LDAP
* Seamless signing of FreeIPA CA us a subCA in Windows Certificate 
Services [https://fedorahosted.org/freeipa/ticket/4496]
* New option --request-cert to optionally request host certificates on 
FreeIPA clients (to /etc/ipa/nssdb/)
* CLI and Web UI for 'retrive keytab' and 'create keytab' authorization 
[http://www.freeipa.org/page/V4/Keytab_Retrieval_Management]

* Services can now be assigned as members of RBAC roles
* `ipa` command run with `-vv` option now prints JSON request and reply 
exchanged with the FreeIPA server. `-vvv` also prints HTTP communication.
* Description attribute is no longer required (e.g. in groups, sudo 
command groups or others) given that it is also not required in schema.

* Packages can be now built and installed on RHEL/CentOS 7.0
* ipa-replica-prepare now waits for the replica DNS record to be 
available to fix race conditions in automated test environments
* Port 8443 is now checked before server installation to prevent 
failures in configuring PKI which uses the port


=== Bug fixes ===
* Server installers can now handle hosts with multiple IPv4 or IPv6 
addresses
* DNS zone interface no longer accepts `--class` option as it had no 
effect as FreeIPA DNS only supports 'IN' class.

* ipa-ldap-upgrade restores Directory Server settings when upgrade fails
* SSLv3.0 (CVE-2014-3566) ciphers are now disabled on new installations

=== DNSSEC Support ===
FreeIPA now automates basic key management for Domain Name System 
Security Extensions (DNSSEC) 
[http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Overview]. 
Before you start signing you DNS zones you have to install DNSSEC key 
master role to an existing FreeIPA DNS server using command:

 ipa-dns-install --dnssec-master

It allows you to enable DNSSEC for particular DNS zone using command:
 ipa dnszone-mod zone.name.example. --dnssec=true

This command will generate new zone keys, distribute keys to all FreeIPA 
DNS servers and configure all servers to independently sign the zone. 
Please keep in mind that it can take few minutes before all servers sign 
the zone.


 Known Limitations 
* User has to manually upload Delegation Signer (DS) record 
[http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Records] 
to parent DNS zone to establish chain of trust.


* User has to manually confirm that DS record in parent zone was 
published otherwise Key Signing Key (KSK) 
[http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Key_management] 
will not be rotated. This confirmation has to be done on FreeIPA server 
with key master role using following command:
  sudo -u ods ods-ksmutil key ds-seen --zone zone.name.example. 
--keytag 12345

* Keytag can be obtained from dig output:
  dig +dnssec zone.name.example. DS

* User is not notified about automated key rotation. This does not lower 
stability of the system because of `ds-seen` logic mentioned above.


* Key and signing policy cannot be changed using FreeIPA tools. 
Currently it is stored in `/etc/opendnssec/kasp.xml` file on DNSSEC key 
master server. Manual changes to `kasp.xml` will be lost during next 
FreeIPA upgrade.


* Only one FreeIPA server can have DNSSEC key master role:
** *Please plan carefully, current version does not allow you to easily 
move DNSSEC master role to a different server.*
** DNSSEC key management will not work when the key master is not 
running, i.e. DNSSEC keys will not be rotated according to the policy 
and keys for new zones will not be generated.


== Known Issues ==
* Directory

Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.

Yet with FreeIPA v4 we've got another thing to keep in mind regarding 
FreeBSD - FreeIPA integration: the cron script proposed at FreeBSD 
forums won't work.

Here's what was said in the post:

The tricky part was gettingsudoto work with host groups. FreeIPA keeps 
host groups in netgroups, and FreeBSD's support for netgroups is 
limited. One solution would have been to enable NIS services on the 
FreeIPA server so that we could use proper netgroups on FreeBSD clients. 
We didn't like that solution, so instead we wrote a script that pulls 
all netgroup data from FreeIPA and stores it in/etc/netgroup. We run the 
script every hour viacron.


The script looks for host groups in 
'cn=hostgroups,cn=accounts,dc=domain', and that works with FreeIPA 
3.3. But in FreeIPA v4 host groups get in 'cn=ng,cn=compat,dc=domain'. 
So the script needs modification.


23-Oct-14 12:09, Orkhan Gasimov пишет:

I already deployed FreeIPA 4.1 on Fedora 21 server alpha-release.
Everything is good as far as FreeIPA server operation is concerned.


23-Oct-14 01:06, William Graboyes пишет:

3) am I insane for wanting to introduce FC21 into my environment?




-- 
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] FreeIPA 3.3.3 and sssd segfault

Hi,
I have a FreeIPA 3.3.3 in transitive trust with AD2008.

Today I saw a lot of sssd segfaults on the server side:

[  420.412011] sssd_be[734]: segfault at 8 ip 7fa54fa73334 sp
7fff62b2ec40 error 4 in libldb.so.1.1.16[7fa54fa66000+2c000]
[  421.763035] sssd_be[2666]: segfault at 8 ip 7f9c5b7ff334 sp
7fff2efadb00 error 4 in libldb.so.1.1.16[7f9c5b7f2000+2c000]
[  494.926197] sssd_be[2668]: segfault at 8 ip 7f0e26194334 sp
7fffd5906140 error 4 in libldb.so.1.1.16[7f0e26187000+2c000]
[  496.247496] sssd_be[2702]: segfault at 8 ip 7feeb5b91334 sp
7fff16a94720 error 4 in libldb.so.1.1.16[7feeb5b84000+2c000]
[  552.856890] sssd_be[2704]: segfault at 8 ip 7f411fafe334 sp
7fff4d551360 error 4 in libldb.so.1.1.16[7f411faf1000+2c000]
[  554.191542] sssd_be[2712]: segfault at 8 ip 7ff55bde7334 sp
7fb0d590 error 4 in libldb.so.1.1.16[7ff55bdda000+2c000]
[  558.502357] sssd_be[2714]: segfault at 8 ip 7f811e75d334 sp
7fff5b624090 error 4 in libldb.so.1.1.16[7f811e75+2c000]
[  572.932207] sssd_be[2717]: segfault at 8 ip 7ff89398e334 sp
7fffa43f6d90 error 4 in libldb.so.1.1.16[7ff893981000+2c000]
[ 2148.965812] sssd_be[2797]: segfault at 8 ip 7fc06f51e334 sp
7fff14f8c8a0 error 4 in libldb.so.1.1.16[7fc06f511000+2c000]
[ 2150.310849] sssd_be[2907]: segfault at 8 ip 7f9fafdef334 sp
7fff29862f10 error 4 in libldb.so.1.1.16[7f9fafde2000+2c000]
[ 2323.836156] sssd_be[2909]: segfault at 8 ip 7f8d6648e334 sp
71249fa0 error 4 in libldb.so.1.1.16[7f8d66481000+2c000]
[ 2325.158687] sssd_be[2917]: segfault at 8 ip 7fb8554ff334 sp
7fffb5f073a0 error 4 in libldb.so.1.1.16[7fb8554f2000+2c000]
[ 2329.361081] sssd_be[2920]: segfault at 8 ip 7fe333e40334 sp
7fffab520290 error 4 in libldb.so.1.1.16[7fe333e33000+2c000]
[ 2343.681005] sssd_be[2922]: segfault at 8 ip 7f0ff5612334 sp
7fff351c9090 error 4 in libldb.so.1.1.16[7f0ff5605000+2c000]
[ 3249.456297] sssd_be[2975]: segfault at 8 ip 7f225d9bb334 sp
7fff43002c80 error 4 in libldb.so.1.1.16[7f225d9ae000+2c000]
[ 3250.661605] sssd_be[2990]: segfault at 8 ip 7fce9bda9334 sp
7fff80076090 error 4 in libldb.so.1.1.16[7fce9bd9c000+2c000]

After the segfault appears, I can not longer login to any ipa client
machine.

RHEL7 -  kernel 3.10.0-123.8.1.el7.x86_64,

ipa-python-3.3.3-28.el7_0.1.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-client-3.3.3-28.el7_0.1.x86_64
libipa_hbac-python-1.11.2-68.el7_0.5.x86_64
iniparser-3.1-5.el7.x86_64
ipa-admintools-3.3.3-28.el7_0.1.x86_64
ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64
sssd-ipa-1.11.2-68.el7_0.5.x86_64
libipa_hbac-1.11.2-68.el7_0.5.x86_64
ipa-server-3.3.3-28.el7_0.1.x86_64

Any idea?

The segfault appears in exactly moment of logging to the ipa client.

/lm
-- 
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] IPA 3.3.3 in transitive trust and random group assignment

Hi List,
On IPA server I added one external group for AD group.

When I log in to IPA client I can see that group:

97687(trustlinuxgroup_from_ad2posix)

 but also I see few different groups came directly from Active Directory
like 127310615(trustlinuxgr...@acme.example.com) or 127200513(domain
us...@acme.example.com):

Afer clearing the cache, the group assignment looks different, few more or
less groups showed by id command.

Do you know the reason? I have no idea what to do with this.

/lm
-- 
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] Woes adding a samba server to the ipa domain

2014-10-23 Thread Sumit Bose

On Tue, Oct 21, 2014 at 07:49:11AM -0430, Loris Santamaria wrote:
 El lun, 20-10-2014 a las 21:19 -0400, Dmitri Pal escribió:
  On 10/20/2014 09:15 AM, Loris Santamaria wrote:
 
 [...]
 
   
   Trying to join the server to the domain (net rpc join -U domainadmin -S
   ipaserver) fails, and it causes a samba crash on the ipa server.
   Investigating the cause of the crash I found that pdbedit crashes as
   well (backtrace attached). I couldn't get a meaningful backtrace from
   the samba crash however I attached it as well.
   
   Seems to me that the samba ipasam backend on ipa doesn't like something
   in the host or the domain computers group object in ldap, but I cannot
   see what could be the problem. Perhaps someone more familiar with the
   ipasam code can spot it quickly.
 
  Do I get it right that you really looking for
  https://fedorahosted.org/sssd/ticket/1588 that was just released
  upstream?
  It would be cool if you can try using SSSD 1.12.1 under Samba FS in
  the use case you have and provide feedback on how it works for you.
  
  AFAIU you install Samba FS and then use ipa-client to configure SSSD
  under it and it should work.
  If not we probably should document it (but I do not see any special
  design page which leads me to the above expectation).
 
 Ok, I'll happily try sssd 1.12.1.
 
 Just a question, in smb.conf one should use security = domain or
 security = ads?

'ads' because we want to use Kerberos. But there some other
configuration options which needs attention, e.g. you have to create a
keytab for the cifs service and make it available to samba. I'll try to
set up an small howto page listing the needed steps and come back to you
early next week.

bye,
Sumit

 
 Best regards
 
 -- 
 Loris Santamaria   linux user #70506   xmpp:lo...@lgs.com.ve
 Links Global Services, C.A.http://www.lgs.com.ve
 Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:1...@lgs.com.ve
 
 If I'd asked my customers what they wanted, they'd have said
 a faster horse - Henry Ford



 -- 
 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] FreeIPA 3.3.3 and sssd segfault

On (23/10/14 12:23), crony wrote:
Hi,
I have a FreeIPA 3.3.3 in transitive trust with AD2008.

Today I saw a lot of sssd segfaults on the server side:

[  420.412011] sssd_be[734]: segfault at 8 ip 7fa54fa73334 sp
7fff62b2ec40 error 4 in libldb.so.1.1.16[7fa54fa66000+2c000]
Could you provide coredump (backtrace) or at least log files with higher
debug_level?

If you have enabled abrt then coredump should be in /var/tmp/abrt/ccpp-*

LS

-- 
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.3 and sssd segfault

Already sent directly to your email.

/lm

2014-10-23 13:45 GMT+02:00 Lukas Slebodnik lsleb...@redhat.com:

 On (23/10/14 12:23), crony wrote:
 Hi,
 I have a FreeIPA 3.3.3 in transitive trust with AD2008.
 
 Today I saw a lot of sssd segfaults on the server side:
 
 [ 420.412011] sssd_be[734]: segfault at 8 ip 7fa54fa73334 sp
 7fff62b2ec40 error 4 in libldb.so.1.1.16[7fa54fa66000+2c000]
 Could you provide coredump (backtrace) or at least log files with higher
 debug_level?

 If you have enabled abrt then coredump should be in /var/tmp/abrt/ccpp-*

 LS




-- 
Pozdrawiam Leszek Miś
www: http://cronylab.pl
www: http://emerge.pl
Nothing is secure, paranoia is your friend.
-- 
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] Attempting to re-provision previous replica

2014-10-23 Thread John Desantis

Rob and Rich,

ipa-replica-manage del should have cleaned things up. You can clear out
old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use
list-ruv to get the id# to clean and clean-ruv to do the actual cleaning.

I remember having previously tried this task, but it had failed on
older RUV's which were not even active (the KDC was under some strain
so ipa queries were timing out). However, I ran it again and have
been able to delete all but 1 (it's still running) RUV referencing the
previous replica.

I'll report back once the tasks finishes or fails.

The last RUV is stuck on another replica. It fails with the following error:

[23/Oct/2014:08:55:09 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Initiating CleanAllRUV Task...
[23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Retrieving maxcsn...
[23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Found maxcsn (5447f8610018)
[23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Cleaning rid (24)...
[23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Waiting to process all the updates from the deleted replica...
[23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Waiting for all the replicas to be online...
[23/Oct/2014:08:55:10 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Waiting for all the replicas to receive all the deleted replica
updates...
[23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Replica maxcsn (5447f56b00020018) is not caught up with deleted
replica's maxcsn(5447f8610018)
[23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Replica not caught up (agmt=cn=meToiparepbackup.our.personal.domain
(iparepbackup:389))
[23/Oct/2014:08:55:11 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Not all replicas caught up, retrying in 10 seconds
[23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Replica maxcsn (5447f56b00020018) is not caught up with deleted
replica's maxcsn(5447f8610018)
[23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Replica not caught up (agmt=cn=meToiparepbackup.our.personal.domain
(iparepbackup:389))
[23/Oct/2014:08:55:23 -0400] NSMMReplicationPlugin - CleanAllRUV Task:
Not all replicas caught up, retrying in 20 seconds

I then abort the task since the retrying went up to 14400 seconds.

Would this be a simple re-initialization from the master on the host
iparepbackup?

Thanks,
John DeSantis

2014-10-22 16:03 GMT-04:00 John Desantis desan...@mail.usf.edu:
Rob and Rich,

I'll report back once the tasks finishes or fails.

Thanks,
John DeSantis

2014-10-22 15:49 GMT-04:00 Rob Crittenden rcrit...@redhat.com:
Rich Megginson wrote:
On 10/22/2014 12:55 PM, John Desantis wrote:
Richard,

You should remove the unused ruv elements. I'm not sure why they
were not
cleaned. You may have to use cleanallruv manually.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv

note - use the cleanallruv procedure, not cleanruv.
I'll try that, thanks for the guidance.

What is the real problem you have? Did replication stop working? Are
you
getting error messages?
I cannot get the host to be a replica. Each time I run
`ipa-replica-install
replica-info-host-in-question.our.personal.domain.gpg' it fails. I
had assumed it was due to the fact that the host was already a
replica, but had to be taken offline due to a hard disk failing. The
machine was re-provisioned after the new hard drive was installed.

Ok. I don't know if we have a documented procedure for that case. I
assumed that if you first ran ipa-replica-manage del, then
ipa-replica-prepare, then ipa-replica-install, that would take care of
that.

When I enabled extra debugging during the installation process, the
initial error was that the dirsrv instance couldn't be started. I
checked into this and found that there were missing files in
/etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv
after copying some schema files from another replica. The

Re: [Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.


And another interesting behaviour.

Say a user netuser is a member of a user group netstaff,
and a host bsd.example.com is a member of a host group nethosts.
We then create an HBAC rule netstaff_to_nethosts:

Who: User Groups - netstaff -- Accessing: Host Groups - nethosts -- 
Via Service: Specified Services and Groups - sshd


And we create a SUDO rule test:

Who: Specified Users and Groups - netuser -- Access this host: 
bsd.example.com -- Run Commands: Any Command


Expected result is this: user netuser should be able to SSH to host 
bsd.example.com and successfully issue the command sudo shutdown -r now.


What happens instead: user netuser is able to SSH to host 
bsd.example.com, but issuing the command sudo shutdown -r now 
produces this output (password is entered correctly):


$ shutdown -r now
Password:
Ying Tong Iddle I Po
Password:
Do you think like you type?
Password:
Have you considered trying to match wits with a rutabaga?

This is funny, and you can continue trying sudo and getting funny 
outputs; but the only way for the command to work properly is to change 
the HBAC rule:


Who: User Groups - netstaff -- Accessing: Host Groups - nethosts -- 
Via Service: Specified Services and Groups - ANY SERVICE


Is this the correct behavior? I don't remember anything like this in 
FreeIPA 3.3.


23-Oct-14 15:21, Orkhan Gasimov пишет:
Yet with FreeIPA v4 we've got another thing to keep in mind regarding 
FreeBSD - FreeIPA integration: the cron script proposed at FreeBSD 
forums won't work.

Here's what was said in the post:

The tricky part was gettingsudoto work with host groups. FreeIPA 
keeps host groups in netgroups, and FreeBSD's support for netgroups is 
limited. One solution would have been to enable NIS services on the 
FreeIPA server so that we could use proper netgroups on FreeBSD 
clients. We didn't like that solution, so instead we wrote a script 
that pulls all netgroup data from FreeIPA and stores it 
in/etc/netgroup. We run the script every hour viacron.


The script looks for host groups in 
'cn=hostgroups,cn=accounts,dc=domain', and that works with FreeIPA 
3.3. But in FreeIPA v4 host groups get in 
'cn=ng,cn=compat,dc=domain'. So the script needs modification.


23-Oct-14 12:09, Orkhan Gasimov пишет:

I already deployed FreeIPA 4.1 on Fedora 21 server alpha-release.
Everything is good as far as FreeIPA server operation is concerned.


23-Oct-14 01:06, William Graboyes пишет:

3) am I insane for wanting to introduce FC21 into my environment?








-- 
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] Attempting to re-provision previous replica

2014-10-23 Thread Rich Megginson

On 10/23/2014 07:01 AM, John Desantis wrote:

Rob and Rich,

I'll report back once the tasks finishes or fails.

The last RUV is stuck on another replica. It fails with the following error:

I then abort the task since the retrying went up to 14400 seconds.

Mark, do you know what is going on here?

Would this be a simple re-initialization from the master on the host
iparepbackup?

Thanks,
John DeSantis

2014-10-22 16:03 GMT-04:00 John Desantis desan...@mail.usf.edu:

Rob and Rich,

I'll report back once the tasks finishes or fails.

Thanks,
John DeSantis

2014-10-22 15:49 GMT-04:00 Rob Crittenden rcrit...@redhat.com:

Rich Megginson wrote:

On 10/22/2014 12:55 PM, John Desantis wrote:

Richard,

note - use the cleanallruv procedure, not cleanruv.

I'll try that, thanks for the guidance.

What is the real problem you have? Did replication stop working? Are
you
getting error messages?

I cannot get the host to be a replica. Each time I run
`ipa-replica-install
replica-info-host-in-question.our.personal.domain.gpg' it fails. I
had assumed it was due to the fact that the host was already a
replica, but had to be taken offline due to a hard disk failing. The
machine was re-provisioned after the new hard drive was installed.

[Freeipa-users] IPA+AD (transitive trust) - s2n exop request failed

Hi All,
I've found another problem with my setup:

What could be the reason of such errors on FreeIPA client side:

/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:49:23 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:03 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:04 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:06 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:06 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:07 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:07 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:08 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:08 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:17 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:05 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:08 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:18 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:57:12 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:57:15 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:58:29 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:58:34 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 10:02:10 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.
/var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 10:02:13 2014)
[sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
exop request failed.

IPA 3.3.3 + RHEL7 and IPA clients: RHEL 6.4 and RHEL 6.6 -  the same
situation.

/lm
-- 
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] IPA+AD (transitive trust) - s2n exop request failed

2014-10-23 Thread Alexander Bokovoy


On Thu, 23 Oct 2014, crony wrote:

Hi All,
I've found another problem with my setup:

What could be the reason of such errors on FreeIPA client side:

You need to check sssd logs on IPA master side.


IPA 3.3.3 + RHEL7 and IPA clients: RHEL 6.4 and RHEL 6.6 -  the same
situation.

There were some bug fixes in SSSD in RHEL7 which are released upstream
in 1.12.x but not yet available through RHEL 7 channels. If you have RHEL 7
subscription, feel free to raise a case with the support.

The same applies to the another email you've sent.
--
/ 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] IPA+AD (transitive trust) - s2n exop request failed

Probable yes.



2014-10-23 15:59 GMT+02:00 Sumit Bose sb...@redhat.com:

 On Thu, Oct 23, 2014 at 03:47:31PM +0200, crony wrote:
  Hi All,
  I've found another problem with my setup:
 
  What could be the reason of such errors on FreeIPA client side:
 
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:49:23 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:03 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:04 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:06 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:06 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:07 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:07 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:08 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:08 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:50:17 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:05 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:08 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:52:18 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:57:12 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:57:15 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:58:29 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 09:58:34 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 10:02:10 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.
  /var/log/sssd/sssd_linux.acme.example.com.log:(Thu Oct 23 10:02:13 2014)
  [sssd[be[linux.acme.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n
  exop request failed.

 This typically indicates that the user or group lookup failed in the
 server side.  Maybe this is related to the segfaults you are seeing on
 the server side.

 bye,
 Sumit

 
  IPA 3.3.3 + RHEL7 and IPA clients: RHEL 6.4 and RHEL 6.6 -  the same
  situation.
 
  /lm

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




-- 
Pozdrawiam Leszek Miś
www: http://cronylab.pl
www: http://emerge.pl
Nothing is secure, paranoia is your friend.
-- 
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] IPA 3.3.3 in transitive trust and random group assignment

2014-10-23 Thread Alexander Bokovoy


On Thu, 23 Oct 2014, crony wrote:

Hi List,
On IPA server I added one external group for AD group.

When I log in to IPA client I can see that group:

97687(trustlinuxgroup_from_ad2posix)

but also I see few different groups came directly from Active Directory
like 127310615(trustlinuxgr...@acme.example.com) or 127200513(domain
us...@acme.example.com):

Afer clearing the cache, the group assignment looks different, few more or
less groups showed by id command.

Do you know the reason? I have no idea what to do with this.

Prior to SSSD 1.12 full group membership was only retrieved during
actual authentication step. With 1.12.2, I think, we have means to pick
up most of the groups before authentication as well, barring those that
are not valid outside of the domain or forest's use (domain local
groups).

--
/ 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] FreeIPA 3.3.3 and sssd segfault

On (23/10/14 14:44), crony wrote:
Already sent directly to your email.

Thank you for coredump.
It is a known bug (https://fedorahosted.org/sssd/ticket/2391)

Bug is fixed in sssd upstream

sh$ git tag --contains 895f045dd4aad7f5857826cc1496cfa048a790dd
sssd-1_11_7

sh$ git tag --contains
82347f452febe3cbffc36b0a3308ffb462515442
sssd-1_12_1
sssd-1_12_2

If you want I can prepare you test package for epel7 in COPR, which will
be equivalent to sssd in fedora 20 (sssd-1.11.7-2.fc20)

LS

-- 
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.3 and sssd segfault

yes, sure, it would be great to see if it works in upstream version.
thank you

2014-10-23 16:10 GMT+02:00 Lukas Slebodnik lsleb...@redhat.com:

 On (23/10/14 14:44), crony wrote:
 Already sent directly to your email.
 
 Thank you for coredump.
 It is a known bug (https://fedorahosted.org/sssd/ticket/2391)

 Bug is fixed in sssd upstream

 sh$ git tag --contains 895f045dd4aad7f5857826cc1496cfa048a790dd
 sssd-1_11_7

 sh$ git tag --contains
 82347f452febe3cbffc36b0a3308ffb462515442
 sssd-1_12_1
 sssd-1_12_2

 If you want I can prepare you test package for epel7 in COPR, which will
 be equivalent to sssd in fedora 20 (sssd-1.11.7-2.fc20)

 LS




-- 
Pozdrawiam Leszek Miś
www: http://cronylab.pl
www: http://emerge.pl
Nothing is secure, paranoia is your friend.
-- 
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.3 and sssd segfault

On (23/10/14 16:31), crony wrote:
yes, sure, it would be great to see if it works in upstream version.
thank you

Here you are
https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-11/

LS

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

2014-10-23 Thread Petr Vobornik


The FreeIPA team would like to announce FreeIPA v4.0.4 bugfix release!

It can be downloaded from http://www.freeipa.org/page/Downloads. Builds 
for Fedora 21 are available in the official COPR repository 
[https://copr.fedoraproject.org/coprs/mkosek/freeipa-4.0/].


== Highlights in 4.0.4 ==
=== Enhancements ===
* Packages can be now built and installed on RHEL/CentOS 7.0
* ipa-replica-prepare now waits for the replica DNS record to be 
available to fix race conditions in automated test environments
* Port 8443 is now checked before server installation to prevent 
failures in configuring PKI which uses the port


=== Bug fixes ===
* Certmonger CAs are now set with correct path to ipa-submit which 
caused problems with new certificate submission
* Directory Server again returns basic RootDSE attributes by default - 
namingContexts, supportedControl, supportedExtension, 
supportedLDAPVersion, supportedSASLMechanisms, vendorName, vendorVersion
* IPA OTP Last Token plugin is now enabled also on upgraded FreeIPA 
servers before 4.0.0
* Better error message is provided if cert-request command fails for 
certificates with SAN
* PKI|CA certificate renewal script (ca_renewal_master) triggered by 
certmonger could fail

* sudorule-add-runasuser command now works with external users
* IPA CA is now properly selected for Web Service and Directory 
Service certificates


== Upgrading ==
An IPA server can be upgraded simply by installing updated rpms. The 
server does not need to be shut down in advance.


Please note that if you are doing the upgrade in special environment 
(e.g. FedUp) which does not allow running the LDAP server during upgrade 
process, upgrade scripts need to be run manually after the first boot:


 # ipa-ldap-updater --upgrade
 # ipa-upgradeconfig

Also note that the performance improvements require an extended set of 
indexes to be configured. RPM update for an IPA server with a excessive 
number of users may require several minutes to finish.


If you have multiple servers you may upgrade them one at a time. It is 
expected that all servers will be upgraded in a relatively short period 
(days or weeks, not months). They should be able to co-exist peacefully 
but new features will not be available on old servers and enrolling a 
new client against an old server will result in the SSH keys not being 
uploaded.


Downgrading a server once upgraded is not supported.

Upgrading from 3.3.0 and later versions is supported. Upgrading from 
previous versions is not supported and has not been tested.


An enrolled client does not need the new packages installed unless you 
want to re-enroll it. SSH keys for already installed clients are not 
uploaded, you will have to re-enroll the client or manually upload the keys.


== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users 
mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or 
#freeipa channel on Freenode.


== Detailed Changelog since 4.0.3 ==

=== Alexander Bokovoy (1) ===
* Default to use TLSv1.0 and TLSv1.1 on the IPA server side

=== David Kupka (5) ===
* Fix example usage in ipa man page.
* Check that port 8443 is available when installing PKI.
* Set IPA CA for freeipa certificates.
* Stop dogtag when updating its configuration in ipa-upgradeconfig.
* Fix typo causing certmonger is provided with wrong path to ipa-submit.

=== Gabe (1) ===
* Missing requires on python-dns in spec file

=== Jan Cholasta (9) ===
* Fix certmonger code causing the ca_renewal_master update plugin to fail
* Allow RPM upgrade from ipa-* packages
* Include ipaplatform in client-only build
* Include the ipa command in client-only build
* Remove misleading authorization error message in cert-request with --add
* Split off generic Red Hat-like platform code from Fedora platform code
* Add RHEL platform module
* Support building RPMs for RHEL/CentOS 7.0
* Do not check if port 8443 is available in step 2 of external CA install

=== Ludwig Krispenz (1) ===
* Ignore irrelevant subtrees in schema compat plugin

=== Martin Basti (2) ===
* dnszone-remove-permission should raise error
* Fix ipactl service ordering

=== Martin Kosek (2) ===
* Sudorule RunAsUser should work with external groups
* Remove changetype attribute from update plugin

=== Nathaniel McCallum (1) ===
* Configure IPA OTP Last Token plugin on upgrade

=== Petr Viktorin (4) ===
* test_permission_plugin: Check legacy permissions
* ipa-replica-prepare: Wait for the DNS entry to be resolvable
* test_forced_client_reenrollment: Don't check for host certificates
* sudo integration test: Remove the local user test

=== Petr Vobornik (4) ===
* webui-ci: case-insensitive record check
* dns: fix privileges' memberof during dns install
* build: increase java stack size for all arches
* Become IPA 4.0.4

=== Sumit Bose (1) ===
* ipa-kdb: fix unit tests

=== Tomas Babej (1) ===
* Set the default attributes for RootDSE
--
Petr Vobornik

--
Manage your subscription for the

[Freeipa-users] Synchronization Agreements between FreeIPA and AD

2014-10-23 Thread Сапегин Валерий

 Hello!

I tryed to configure synchronization between FreeIPA and  Windows AD 2012.
In the thirst time accounts from AD synchronization properly but next
schedule after 5 min is not work and in error log I see the following
errors:

# tail -f /var/log/dirsrv/slapd-TEST-CSBI-ITS-RU/errors
[23/Oct/2014:15:51:34 +0300] NSMMReplicationPlugin - agmt=cn=
meTocsbi-it-dc01.csbigroup.ru (csbi-it-dc01:389): Replica has no update
vector. It has never been initialized.
[23/Oct/2014:15:51:37 +0300] NSMMReplicationPlugin - agmt=cn=
meTocsbi-it-dc01.csbigroup.ru (csbi-it-dc01:389): Replica has no update
vector. It has never been initialized.
[23/Oct/2014:15:51:40 +0300] NSMMReplicationPlugin - agmt=cn=
meTocsbi-it-dc01.csbigroup.ru (csbi-it-dc01:389): Replica has no update
vector. It has never been initialized.

Thirst synchronization out

Added CA certificate /etc/openldap/certs/CSBIGROUP-CA.crt to certificate
database for ipa.test-csbi-its.ru
ipa: INFO: AD Suffix is: DC=csbigroup,DC=ru
The user for the Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=test-csbi-its,dc=ru
Windows PassSync entry exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready . . .
ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica
acquired successfully: Incremental update started: start: 0: end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
Update in progress, 13 seconds elapsed
[ipa.test-csbi-its.ru] reports: Update failed! Status: [-1 Total update
abortedLDAP error: Can't contact LDAP server]

Failed to start replication



FreeIPA server version 3.3.3
OS version Centos 7
AD Domain 2012

Can you help me to resolve this problem?

Best regards, Valeriy
-- 
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] Recovering from messed-up certs

2014-10-23 Thread Eric McCoy

Hi all,

I somehow destroyed my primary IPA server's Server-Cert in
/etc/httpd/alias.  I don't understand how or why it happened, all I know is
that I went to restart Apache and it was gone.  Apache won't start, of
course, because the cert is missing.  I can't issue a new cert on the
primary because Apache is down.  I tried using the secondary, but it fails
saying that it can't connect to the web server on the primary (it's the
same error message I get when I try to issue a cert from the primary).  I
can't figure out how to tell ipa-getcert et al. to talk to the secondary
and not the primary.  I'm not using DNS for service discovery, so I'm not
sure how the various tools figure out where things are.

This is all on CentOS 6.5 with IPA 3.0.0-37.
-- 
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.3 and sssd segfault

Thank you!

Error: Package: sssd-client-1.11.7-2.el7.centos.x86_64 (lslebodn-sssd-1-11)
   Requires: libc.so.6(GLIBC_2.14)(64bit)
Error: Package: python-sssdconfig-1.11.7-2.el7.centos.noarch
(lslebodn-sssd-1-11)
   Requires: python(abi) = 2.7
   Installed: python-2.6.6-52.el6.x86_64 (@updates)
   python(abi) = 2.6
   Available: python-2.6.6-51.el6.x86_64 (base)
   python(abi) = 2.6

Should I change the default python from RHEL7 for dependencies? It could be
destructive for my system ;-)

2014-10-23 17:09 GMT+02:00 Lukas Slebodnik lsleb...@redhat.com:

 On (23/10/14 16:31), crony wrote:
 yes, sure, it would be great to see if it works in upstream version.
 thank you
 
 Here you are
 https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-11/

 LS




-- 
Pozdrawiam Leszek Miś
www: http://cronylab.pl
www: http://emerge.pl
Nothing is secure, paranoia is your friend.
-- 
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] A crazy idea maybe, migration to Free-IPA 4.1.

2014-10-23 Thread Орхан Касумов


Alright then, thanks for info!
Tomorrow is the deadline for my researches on FreeIPA.
Then I have to start deploying a centralized management solution in our 
production environment.
Please help me to make a final decision on which version of FreeIPA to choose - 
3.3 or 4.1?
I'd like to have all the benefits of the latest version, but all our production 
servers are FreeBSD.
With all information sources at my disposal right now I tend to choose FreeIPA 
3.3.
The cause is that otherwise I can't use host groups with sudo commands -
the cron script proposed at FreeBSD forums works with old way of storing host 
group information in the LDAP directory of FreeIPA.
Is there any workaround for this? (P.S. Here's what I'm talking about:
 The tricky part was getting  sudo  to work with host groups. FreeIPA keeps 
host groups in netgroups, and FreeBSD's support for netgroups is limited. One 
solution would have been to enable NIS services on the FreeIPA server so that 
we could use proper netgroups on FreeBSD clients. We didn't like that 
solution, so instead we wrote a script that pulls all netgroup data from 
FreeIPA and stores it in  /etc/netgroup . We run the script every hour via  
cron . 

The script looks for host groups in 'cn=hostgroups,cn=accounts,dc=domain', 
and that works with FreeIPA 3.3. But in FreeIPA v4 host groups get in 
'cn=ng,cn=compat,dc=domain'. So the script needs modification. But I don't 
know how to modify the script, simply changing the string passed to the 
ldapsearch command doesn't work.)


Thu, 23 Oct 2014 16:41:55 +0300 от Alexander Bokovoy aboko...@redhat.com:
On Thu, 23 Oct 2014, Orkhan Gasimov wrote:
And another interesting behaviour.

Say a user netuser is a member of a user group netstaff,
and a host bsd.example.com is a member of a host group nethosts.
We then create an HBAC rule netstaff_to_nethosts:

Who: User Groups - netstaff -- Accessing: Host Groups - nethosts -- 
Via Service: Specified Services and Groups - sshd
Here you are allowing only sshd service for use.


And we create a SUDO rule test:

Who: Specified Users and Groups - netuser -- Access this host: 
bsd.example.com -- Run Commands: Any Command

Expected result is this: user netuser should be able to SSH to host 
bsd.example.com and successfully issue the command sudo shutdown -r 
now.

What happens instead: user netuser is able to SSH to host 
bsd.example.com, but issuing the command sudo shutdown -r now 
produces this output (password is entered correctly):

$ shutdown -r now
Password:
Ying Tong Iddle I Po
Password:
Do you think like you type?
Password:
Have you considered trying to match wits with a rutabaga?

This is funny, and you can continue trying sudo and getting funny 
outputs; but the only way for the command to work properly is to 
change the HBAC rule:

Who: User Groups - netstaff -- Accessing: Host Groups - nethosts -- 
Via Service: Specified Services and Groups - ANY SERVICE

Is this the correct behavior? I don't remember anything like this in 
FreeIPA 3.3.
Yes. The behaviour did not change since may be FreeIPA 2.0.

sudo does authenticate and authorize user first via PAM stack and then applies 
own
ruleset. So HBAC rules get applied here and since you don't have
allow_all rule that would allow any user to access any service on any
host, you get denial.

Instead of using only sshd service in HBAC rule, make a service group
and add both sshd and sudo there.

Alternatively you can add multiple HBAC rules, one for sshd, one for
sudo.


-- 
/ 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] FreeIPA 3.3.3 and sssd segfault

On (23/10/14 18:12), crony wrote:
Thank you!

I prepared repo for epel6, epel7 and fedora 19

Error: Package: sssd-client-1.11.7-2.el7.centos.x86_64 (lslebodn-sssd-1-11)
   Requires: libc.so.6(GLIBC_2.14)(64bit)
Error: Package: python-sssdconfig-1.11.7-2.el7.centos.noarch

you want to install package from epel7

(lslebodn-sssd-1-11)
   Requires: python(abi) = 2.7
   Installed: python-2.6.6-52.el6.x86_64 (@updates)
   ^^^
   and machine is rhel6 (centos6)

   python(abi) = 2.6
   Available: python-2.6.6-51.el6.x86_64 (base)
   python(abi) = 2.6

Should I change the default python from RHEL7 for dependencies? It could be
destructive for my system ;-)
Are you sure you are using RHEL7 and not RHEL6?

LS

-- 
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] A crazy idea maybe, migration to Free-IPA 4.1.

2014-10-23 Thread Alexander Bokovoy


On Thu, 23 Oct 2014, Орхан Касумов wrote:


Alright then, thanks for info!
Tomorrow is the deadline for my researches on FreeIPA.
Then I have to start deploying a centralized management solution in our 
production environment.
Please help me to make a final decision on which version of FreeIPA to choose - 
3.3 or 4.1?
I'd like to have all the benefits of the latest version, but all our production 
servers are FreeBSD.
With all information sources at my disposal right now I tend to choose FreeIPA 
3.3.
The cause is that otherwise I can't use host groups with sudo commands -
the cron script proposed at FreeBSD forums works with old way of storing host 
group information in the LDAP directory of FreeIPA.
Is there any workaround for this? (P.S. Here's what I'm talking about:

 The tricky part was getting  sudo  to work with host groups. FreeIPA
keeps host groups in netgroups, and FreeBSD's support for netgroups is
limited. One solution would have been to enable NIS services on the
FreeIPA server so that we could use proper netgroups on FreeBSD
clients. We didn't like that solution, so instead we wrote a script
that pulls all netgroup data from FreeIPA and stores it in 
/etc/netgroup . We run the script every hour via  cron . 

The script looks for host groups in
'cn=hostgroups,cn=accounts,dc=domain', and that works with FreeIPA
3.3. But in FreeIPA v4 host groups get in
'cn=ng,cn=compat,dc=domain'. So the script needs modification. But I
don't know how to modify the script, simply changing the string passed
to the ldapsearch command doesn't work.)

I think you completely missed the way FreeIPA works. :)

Host groups are always in cn=hostgroups,cn=accounts,$SUFFIX, no changes
were done.

What you see in cn=ng,cn=compat,$SUFFIX are net groups for compatibility
with older applications which expect old LDAP schema. The tree in
cn=compat,$SUFFIX is provided through schema compatibility plugin and
was also provided this way for quite a long time.

What I think you are stumbling upon is the fact that starting with
FreeIPA 4.0 we are providing more fine-grained access control to the
data in LDAP tree. 


For example:
$ ipa permission-find --subtree=cn=hostgroups,cn=accounts,dc=ipacloud,dc=test  
--right=read
-
2 permissions matched
-
 Permission name: System: Read Hostgroup Membership
 Granted rights: read, compare, search
 Effective attributes: member, memberhost, memberof, memberuser
 Default attributes: member, memberof, memberuser, memberhost
 Bind rule type: all
 Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test
 Type: hostgroup

 Permission name: System: Read Hostgroups
 Granted rights: read, compare, search
 Effective attributes: businesscategory, cn, createtimestamp,
description, entryusn, ipauniqueid, modifytimestamp, o, objectclass, ou,
owner, seealso
 Default attributes: cn, businesscategory, objectclass, description, o,
ipauniqueid, owner, ou, seealso
 Bind rule type: all
 Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test
 Type: hostgroup

Number of entries returned 2


As you can see, both permissions require bind rule type 'all' which
means 'all authenticated users'.

On contrast, in schema compat tree you'll get the whole tree anonymously

$ ipa permission-find --target=cn=ng,cn=compat,dc=ipacloud,dc=test --right=read

1 permission matched

 Permission name: System: Read Netgroup Compat Tree
 Granted rights: read, compare, search
 Effective attributes: cn, createtimestamp, entryusn, membernisnetgroup, 
modifytimestamp, nisnetgrouptriple, objectclass
 Default attributes: objectclass, nisnetgrouptriple, membernisnetgroup, cn
 Bind rule type: anonymous
 Subtree: dc=ipacloud,dc=test
 Target DN: cn=ng,cn=compat,dc=ipacloud,dc=test

Number of entries returned 1


This means that your script should work as before, only that it needs to
authenticate before connecting. As you run it as root, you can use host
keytab, try adding something like this:

old_krb5_ccache=${KRB5_CCACHE}
KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$
export KRB5_CCACHE
kinit -k -t /etc/krb5.keytab host/`hostname`
# perform actual search
ldapsearch -Y GSSAPI .

# end of script
kdestroy
KRB5_CCACHE=${old_krb5_ccache}
export KRB5_CCACHE

note that ldapsearch -Y GSSAPI will use Kerberos authentication when
talking to IPA LDAP server and use host/`hostname` principal for that.
This should be enough for allowing access to the host groups.

--
/ 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] Recovering from messed-up certs

2014-10-23 Thread Rob Crittenden

Eric McCoy wrote:
 Hi all,
 
 I somehow destroyed my primary IPA server's Server-Cert in
 /etc/httpd/alias.  I don't understand how or why it happened, all I know
 is that I went to restart Apache and it was gone.  Apache won't start,
 of course, because the cert is missing.  I can't issue a new cert on the
 primary because Apache is down.  I tried using the secondary, but it
 fails saying that it can't connect to the web server on the primary
 (it's the same error message I get when I try to issue a cert from the
 primary).  I can't figure out how to tell ipa-getcert et al. to talk to
 the secondary and not the primary.  I'm not using DNS for service
 discovery, so I'm not sure how the various tools figure out where things
 are.
 
 This is all on CentOS 6.5 with IPA 3.0.0-37.
 
 

What certs do you have in the database?

# certutil -L -d /etc/httpd/alias

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] Synchronization Agreements between FreeIPA and AD

2014-10-23 Thread Rich Megginson


On 10/23/2014 10:26 AM, Dmitri Pal wrote:

On 10/23/2014 08:19 AM, Сапегин Валерий wrote:

Hello!

I tryed to configure synchronization between FreeIPA and  Windows AD 
2012. In the thirst time accounts from AD synchronization properly 
but next schedule after 5 min is not work and in error log I see the 
following errors:


# tail -f /var/log/dirsrv/slapd-TEST-CSBI-ITS-RU/errors
[23/Oct/2014:15:51:34 +0300] NSMMReplicationPlugin - 
agmt=cn=meTocsbi-it-dc01.csbigroup.ru 
http://meTocsbi-it-dc01.csbigroup.ru (csbi-it-dc01:389): Replica 
has no update vector. It has never been initialized.
[23/Oct/2014:15:51:37 +0300] NSMMReplicationPlugin - 
agmt=cn=meTocsbi-it-dc01.csbigroup.ru 
http://meTocsbi-it-dc01.csbigroup.ru (csbi-it-dc01:389): Replica 
has no update vector. It has never been initialized.
[23/Oct/2014:15:51:40 +0300] NSMMReplicationPlugin - 
agmt=cn=meTocsbi-it-dc01.csbigroup.ru 
http://meTocsbi-it-dc01.csbigroup.ru (csbi-it-dc01:389): Replica 
has no update vector. It has never been initialized.


Thirst synchronization out

Added CA certificate /etc/openldap/certs/CSBIGROUP-CA.crt to 
certificate database for ipa.test-csbi-its.ru 
http://ipa.test-csbi-its.ru

ipa: INFO: AD Suffix is: DC=csbigroup,DC=ru
The user for the Windows PassSync service is 
uid=passsync,cn=sysaccounts,cn=etc,dc=test-csbi-its,dc=ru

Windows PassSync entry exists, not resetting password
ipa: INFO: Added new sync agreement, waiting for it to become ready . . .
ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica 
acquired successfully: Incremental update started: start: 0: end: 0

ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
Update in progress, 13 seconds elapsed
[ipa.test-csbi-its.ru http://ipa.test-csbi-its.ru] reports: Update 
failed! Status: [-1 Total update abortedLDAP error: Can't contact 
LDAP server]


Can you connect from this replica to AD using ldapsearch?


specifically
$ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-YOUR-DOMAIN ldapsearch -xLLL -ZZ 
-h fqdn.of.windows.machine -D 
cn=administrator,cn=users,dc=csbigroup,dc=ru -w windows admin 
password -s base -b cn=users,dc=csbigroup,dc=ru






Failed to start replication



FreeIPA server version 3.3.3
OS version Centos 7
AD Domain 2012

Can you help me to resolve this problem?

Best regards, Valeriy





--
Thank you,
Dmitri Pal

Sr. Engineering Manager 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] A crazy idea maybe, migration to Free-IPA 4.1.

Very interesting!

You're right, I used simple  ldapsearch -x command on the client when 
browsing the LDAP database. With IPA 3.3 it returned a whole lot of info about 
hostgroups, but with IPA 4.1 - only a single string 'cn=ng,cn=compat,$SUFFIX'. 
That's why current script didn't work.

Tomorrow at work I'll try your advice, and if there's no another problem 
between the chair and the keyboard, I'll definitely stick with FreeIPA 4.1!

Отправлено от Blue Mail



На 21:40, 23.10.2014, в 21:40, Alexander Bokovoy aboko...@redhat.com 
написал:пOn Thu, 23 Oct 2014, Орхан Касумов wrote:

Alright then, thanks for info!
Tomorrow is the deadline for my researches on FreeIPA.
Then I have to start deploying a centralized management solution in
our production environment.
Please help me to make a final decision on which version of FreeIPA to
choose - 3.3 or 4.1?
I'd like to have all the benefits of the latest version, but all our
production servers are FreeBSD.
With all information sources at my disposal right now I tend to choose
FreeIPA 3.3.
The cause is that otherwise I can't use host groups with sudo commands
-
the cron script proposed at FreeBSD forums works with old way of
storing host group information in the LDAP directory of FreeIPA.
Is there any workaround for this? (P.S. Here's what I'm talking about:
 The tricky part was getting  sudo  to work with host groups.
FreeIPA
keeps host groups in netgroups, and FreeBSD's support for netgroups
is
limited. One solution would have been to enable NIS services on the
FreeIPA server so that we could use proper netgroups on FreeBSD
clients. We didn't like that solution, so instead we wrote a script
that pulls all netgroup data from FreeIPA and stores it in 
/etc/netgroup . We run the script every hour via  cron . 

The script looks for host groups in
'cn=hostgroups,cn=accounts,dc=domain', and that works with FreeIPA
3.3. But in FreeIPA v4 host groups get in
'cn=ng,cn=compat,dc=domain'. So the script needs modification. But
I
don't know how to modify the script, simply changing the string
passed
to the ldapsearch command doesn't work.)
I think you completely missed the way FreeIPA works. :)

Host groups are always in cn=hostgroups,cn=accounts,$SUFFIX, no changes
were done.

What you see in cn=ng,cn=compat,$SUFFIX are net groups for
compatibility
with older applications which expect old LDAP schema. The tree in
cn=compat,$SUFFIX is provided through schema compatibility plugin and
was also provided this way for quite a long time.

What I think you are stumbling upon is the fact that starting with
FreeIPA 4.0 we are providing more fine-grained access control to the
data in LDAP tree. 

For example:
$ ipa permission-find
--subtree=cn=hostgroups,cn=accounts,dc=ipacloud,dc=test  --right=read
-
2 permissions matched
-
  Permission name: System: Read Hostgroup Membership
  Granted rights: read, compare, search
  Effective attributes: member, memberhost, memberof, memberuser
  Default attributes: member, memberof, memberuser, memberhost
  Bind rule type: all
  Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test
  Type: hostgroup

  Permission name: System: Read Hostgroups
  Granted rights: read, compare, search
  Effective attributes: businesscategory, cn, createtimestamp,
description, entryusn, ipauniqueid, modifytimestamp, o, objectclass,
ou,
owner, seealso
 Default attributes: cn, businesscategory, objectclass, description, o,
ipauniqueid, owner, ou, seealso
  Bind rule type: all
  Subtree: cn=hostgroups,cn=accounts,dc=ipacloud,dc=test
  Type: hostgroup

Number of entries returned 2


As you can see, both permissions require bind rule type 'all' which
means 'all authenticated users'.

On contrast, in schema compat tree you'll get the whole tree
anonymously

$ ipa permission-find --target=cn=ng,cn=compat,dc=ipacloud,dc=test
--right=read

1 permission matched

  Permission name: System: Read Netgroup Compat Tree
  Granted rights: read, compare, search
Effective attributes: cn, createtimestamp, entryusn, membernisnetgroup,
modifytimestamp, nisnetgrouptriple, objectclass
Default attributes: objectclass, nisnetgrouptriple, membernisnetgroup,
cn
  Bind rule type: anonymous
  Subtree: dc=ipacloud,dc=test
  Target DN: cn=ng,cn=compat,dc=ipacloud,dc=test

Number of entries returned 1


This means that your script should work as before, only that it needs
to
authenticate before connecting. As you run it as root, you can use host
keytab, try adding something like this:

old_krb5_ccache=${KRB5_CCACHE}
KRB5_CCACHE=/tmp/_hostgroups_access.ccache.$$
export KRB5_CCACHE
kinit -k -t /etc/krb5.keytab host/`hostname`
# perform actual search
ldapsearch -Y GSSAPI .

# end of script
kdestroy
KRB5_CCACHE=${old_krb5_ccache}
export KRB5_CCACHE

note that ldapsearch -Y GSSAPI will use Kerberos

Re: [Freeipa-users] FreeIPA 3.3.3 and sssd segfault

Oh, sorry Lukas, now its my mistake + tiredness.. I was testing on the
wrong machine.Thank you.

/lm

2014-10-23 18:30 GMT+02:00 Lukas Slebodnik lsleb...@redhat.com:

 On (23/10/14 18:12), crony wrote:
 Thank you!
 
 I prepared repo for epel6, epel7 and fedora 19

 Error: Package: sssd-client-1.11.7-2.el7.centos.x86_64
 (lslebodn-sssd-1-11)
Requires: libc.so.6(GLIBC_2.14)(64bit)
 Error: Package: python-sssdconfig-1.11.7-2.el7.centos.noarch
 
 you want to install package from epel7

 (lslebodn-sssd-1-11)
Requires: python(abi) = 2.7
Installed: python-2.6.6-52.el6.x86_64 (@updates)
^^^
and machine is rhel6 (centos6)

python(abi) = 2.6
Available: python-2.6.6-51.el6.x86_64 (base)
python(abi) = 2.6
 
 Should I change the default python from RHEL7 for dependencies? It could
 be
 destructive for my system ;-)
 Are you sure you are using RHEL7 and not RHEL6?

 LS




-- 
Pozdrawiam Leszek Miś
www: http://cronylab.pl
www: http://emerge.pl
Nothing is secure, paranoia is your friend.
-- 
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] Recovering from messed-up certs

2014-10-23 Thread Eric McCoy

Some nicknames changed to protect the innocent.  The puppetmaster/hostname
cert is nominally unrelated, though its creation was contemporaneous with
the disappearance of server-cert so I can't entirely rule it out.

Certificate Nickname Trust
Attributes

SSL,S/MIME,JAR/XPI

puppetmaster/hostname u,u,u
REALMNAME IPA CA CT,C,C
ipaCert  u,u,u
Signing-Cert u,u,u


On Thu, Oct 23, 2014 at 12:53 PM, Rob Crittenden rcrit...@redhat.com
wrote:

 Eric McCoy wrote:
  Hi all,
 
  I somehow destroyed my primary IPA server's Server-Cert in
  /etc/httpd/alias.  I don't understand how or why it happened, all I know
  is that I went to restart Apache and it was gone.  Apache won't start,
  of course, because the cert is missing.  I can't issue a new cert on the
  primary because Apache is down.  I tried using the secondary, but it
  fails saying that it can't connect to the web server on the primary
  (it's the same error message I get when I try to issue a cert from the
  primary).  I can't figure out how to tell ipa-getcert et al. to talk to
  the secondary and not the primary.  I'm not using DNS for service
  discovery, so I'm not sure how the various tools figure out where things
  are.
 
  This is all on CentOS 6.5 with IPA 3.0.0-37.
 
 

 What certs do you have in the database?

 # certutil -L -d /etc/httpd/alias

 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] Recovering from messed-up certs

2014-10-23 Thread Rob Crittenden

Eric McCoy wrote:
 Some nicknames changed to protect the innocent.  The
 puppetmaster/hostname cert is nominally unrelated, though its creation
 was contemporaneous with the disappearance of server-cert so I can't
 entirely rule it out.
 
 Certificate Nickname Trust
 Attributes
 
 SSL,S/MIME,JAR/XPI
 
 puppetmaster/hostname u,u,u
 REALMNAME IPA CA CT,C,C
 ipaCert  u,u,u
 Signing-Cert u,u,u

Ok, this is good. If we have ipaCert we can get a cert directly from the
CA like we do during installation.

The attached python script should fix things up for you.

Save it, modify it and replace subjectbase with what matches your
environment. You can get the base from an existing cert with:

# certutil -L -d /etc/dirsrv/slapd-REALM -n Server-Cert |grep Subject

Unless you changed it during installation it should be O=REALM

Then just run the script:

# python newcert.py
Initializing API
Setting up NSS databases
Untracking existing Apache Server-Cert
Issuing new cert
Tracking Server-Cert

# service httpd start

The only thing this script doesn't do is put this updated certificate in
the service record's LDAP entry.

rob

 
 
 On Thu, Oct 23, 2014 at 12:53 PM, Rob Crittenden rcrit...@redhat.com
 mailto:rcrit...@redhat.com wrote:
 
 Eric McCoy wrote:
  Hi all,
 
  I somehow destroyed my primary IPA server's Server-Cert in
  /etc/httpd/alias.  I don't understand how or why it happened, all
 I know
  is that I went to restart Apache and it was gone.  Apache won't start,
  of course, because the cert is missing.  I can't issue a new cert
 on the
  primary because Apache is down.  I tried using the secondary, but it
  fails saying that it can't connect to the web server on the primary
  (it's the same error message I get when I try to issue a cert from the
  primary).  I can't figure out how to tell ipa-getcert et al. to
 talk to
  the secondary and not the primary.  I'm not using DNS for service
  discovery, so I'm not sure how the various tools figure out where
 things
  are.
 
  This is all on CentOS 6.5 with IPA 3.0.0-37.
 
 
 
 What certs do you have in the database?
 
 # certutil -L -d /etc/httpd/alias
 
 rob
 
 

from ipalib import api
from ipaserver.install import certs
from ipaserver.install.installutils import get_fqdn

# SET THIS TO YOUR ENVIRONMENT
subject_base=O=EXAMPLE.COM

print Initializing API
api.bootstrap(context='fixup')
api.finalize()

fqdn = get_fqdn()
principal = HTTP/%s@%s % (fqdn, api.env.realm)

print Setting up NSS databases
ca_db = certs.CertDB(api.env.realm, host_name=fqdn, subject_base=subject_base)

db = certs.CertDB(api.env.realm, subject_base=subject_base)

print Untracking existing Apache Server-Cert
db.untrack_server_cert(Server-Cert)

print Issuing new cert
dercert = db.create_server_cert(Server-Cert, fqdn, ca_db)

print Tracking Server-Cert
db.track_server_cert(Server-Cert, principal, db.passwd_fname, 'restart_httpd')
-- 
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] Inconsistent group memberships in sssd

2014-10-23 Thread Michael Lasevich

FreeIPA 4.0.3 server with SSSD 1.9.2 on CentOS6

Seems that group membership is completely inconsistent

Running id in shell as my user on:
  * ipa server - I am a member of 2 groups
  * Server that just came up and joined - 1 group
  * Server that has been up for some time  - 5 groups

Via UI: Member of 7 groups directly and 1 indirect

Gets weirder - I added a line to sudoers file (not ipa sudo support, can't
get that to work) allowing certain group I am a member of. If I run sudo as
the user - i get rejected as not being in sudoers, however if I run check
as root:

sudo -l -U username

I see that I should be allowed.

More wierdness, If I do getent group groupname - it shows me as a
member - but
I do not recall having this much trouble with same sssd and 3.0 server :-(

Any thoughts?

-M
-- 
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] Inconsistent group memberships in sssd

2014-10-23 Thread Michael Lasevich

Small update, it appears that once I run getent group groupname - my
user shows up in the group groupname. Odd.

(and yes, I have ran sss_cache -UG many a time)

-M

On Thu, Oct 23, 2014 at 5:15 PM, Michael Lasevich mlasev...@gmail.com
wrote:

 FreeIPA 4.0.3 server with SSSD 1.9.2 on CentOS6

 Seems that group membership is completely inconsistent

 Running id in shell as my user on:
   * ipa server - I am a member of 2 groups
   * Server that just came up and joined - 1 group
   * Server that has been up for some time  - 5 groups

 Via UI: Member of 7 groups directly and 1 indirect

 Gets weirder - I added a line to sudoers file (not ipa sudo support, can't
 get that to work) allowing certain group I am a member of. If I run sudo as
 the user - i get rejected as not being in sudoers, however if I run check
 as root:

 sudo -l -U username

 I see that I should be allowed.

 More wierdness, If I do getent group groupname - it shows me as a
 member - but
 I do not recall having this much trouble with same sssd and 3.0 server :-(

 Any thoughts?

 -M


-- 
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] No result when trying to integrate a FreeBSD client with the FreeIPA server

2014-10-23 Thread Fraser Tweedale

On Thu, Oct 23, 2014 at 02:12:47PM +0400, Орхан Касумов wrote:
  +1.
 And even if talking about installation of the necessary software and not 
 about the configuration, then why this?
 
  The commands to enable the custom repository and install the required 
 packages on a FreeBSD host appear below.
 Note that these are  Bourne  shell commands; this script will not work in the 
 FreeBSD default shell  csh . 
 
 After having baked ONE SET OF DEFAULTS into a custom package (to make our 
 lives easier), you leave readers to mess with ANOTHER SET OF DEFAULTS, i.e. 
 to change FreeBSD's shells?

It is only for that one script (because csh heredocs are weird).
There is no need whatsoever for a chsh; just that one script needs
to be executed in /bin/sh.  I will clarify this in the post.

 Aren't there some discrepancies? It may be simple / useful / interesting to 
 change shells, but why not make a self-sufficient article?
 Please update your article to provide a full picture of what a user should do 
 to install all necessary software, and also which parts should be installed 
 from your repo, and which parts should be installed from ports (+ the correct 
 order).
 You've already done a lot of work, but with this refinement your help will be 
 even more valuable.
 I'm not asking for myself personally (I've already accomplished all necessary 
 tasks) - just IMHO everyone writing instructions, tutorials and HowTos for 
 the *nix world should stick to the rule: articles should be self-sufficient.
 I.e. if they rely on techniques not detailed in them, they should at least 
 include links to other WORKING articles to ensure that a reader will be able 
 to COMPLETE a task.
 Thanks for your contribution, Fraser.

 
 
 Thu, 23 Oct 2014 09:58:33 +0200 от Lukas Slebodnik lsleb...@redhat.com:
 On (23/10/14 11:27), Outback Dingo wrote:
 On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale  ftwee...@redhat.com 
 wrote:
 
  On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote:
   On (22/10/14 17:10), Fraser Tweedale wrote:
   Further to my earlier email, I have written a blog post about all
   these matters, with a particular focus on the custom package repo.
   
   I will update it tomorrow with a bit more about the package
   flavours topic.  For now, all the details for enabling and using
   the custom repo are in the post.  Check it out and let me know if
   you spot any issues.
   
   
   
  http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/
   
   The disadvantage of this approach is that users need to rely on updating
   of non standard repo.  https://frase.id.au/pkg/${ABI}_FreeIPA
  
   In my opinion, it's better to write howto (script) which will configure
  all
   necessary ports/files and portmaster will take care of updating ports.
https://www.freebsd.org/doc/handbook/ports-using.html#portmaster
  
   LS
 
  Each has its advantages and disadvantages; people can choose what
  works for them.  Hopefully - not too far in the future - people
  won't have to choose, when binary package flavours are
  implemented.  When that happens, a small effort will be needed to
  define the FreeIPA flavour and ensure it gets included in the
  official package repos.
 
 Fraser you missed one main point of this thread. The most problematic was
 to *configure* all files and not install sssd. I don't want to say that
 installing is super easy, but configuration is much more complicated.
 
 
 Actually I would be inclined to assist with a ports build, so it could be
 done correctly from the ports tree
 and work towards having it adopted into mainline.
 
 +1
 
 LS
 
 -- 
 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] No result when trying to integrate a FreeBSD client with the FreeIPA server

2014-10-23 Thread Fraser Tweedale

On Thu, Oct 23, 2014 at 09:58:33AM +0200, Lukas Slebodnik wrote:
 On (23/10/14 11:27), Outback Dingo wrote:
 On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale ftwee...@redhat.com
 wrote:
 
  On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote:
   On (22/10/14 17:10), Fraser Tweedale wrote:
   Further to my earlier email, I have written a blog post about all
   these matters, with a particular focus on the custom package repo.
   
   I will update it tomorrow with a bit more about the package
   flavours topic.  For now, all the details for enabling and using
   the custom repo are in the post.  Check it out and let me know if
   you spot any issues.
   
   
  http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/
   
   The disadvantage of this approach is that users need to rely on updating
   of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA
  
   In my opinion, it's better to write howto (script) which will configure
  all
   necessary ports/files and portmaster will take care of updating ports.
   https://www.freebsd.org/doc/handbook/ports-using.html#portmaster
  
   LS
 
  Each has its advantages and disadvantages; people can choose what
  works for them.  Hopefully - not too far in the future - people
  won't have to choose, when binary package flavours are
  implemented.  When that happens, a small effort will be needed to
  define the FreeIPA flavour and ensure it gets included in the
  official package repos.
 
 Fraser you missed one main point of this thread. The most problematic was
 to *configure* all files and not install sssd. I don't want to say that
 installing is super easy, but configuration is much more complicated.
 

I haven't missed that point at all.  In the post I am up front about
the difficulty and room for error in configuring all the services,
and in the conclusion I talk about the scope for further work with a
port of ipa-client-install.

I will clarify the post to try and make it clearer that it focuses
on the installation aspect of the setup and leaves other aspects for
another day.

Thanks for your feedback,

Fraser

 
 Actually I would be inclined to assist with a ports build, so it could be
 done correctly from the ports tree
 and work towards having it adopted into mainline.
 
 +1
 
 LS

-- 
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] Third party SSL certificate renewal

2014-10-23 Thread Dragan Prostran

Hello,

This is my first time posting to this list, so if I've made a faux pas
or mistake, please do correct me.

Can anyone please point me to the correct method to renewing 3rd party
SSL certificates used by FreeIPA 3.0? I suspect I've not done this
correctly.

Here is what has worked correctly so far:
1. FreeIPA is installed and configured to work correctly. It uses 3rd
party SSL certificates. I have access to the CSR, the certificate, the
private key, and the new CA bundle.
2. I have successfully followed these instructions to update the SSL
certificates used by Apache to serve the FreeIPA web interface:
http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP.
Of note is that there are 2 IPA servers, and the procedure has been
followed on both.
3. Upon visiting the FreeIPA web interface, I can see that the
certificate is valid, and expires in the future. Login to FreeIPA and
modifying (for example) an LDAP password, work correctly.
4. 3rd party services that take advantage of LDAP work correctly. I
can login and authenticate via LDAP.

Here is what does not work correctly:
1. A distinct, 3rd party webservice that takes advantage of LDAP *via
SSL* no longer is able to authenticate. Prior to certificate update
mentioned, this did work correctly. I must admit I'm unfamiliar with
LDAP (via SSL), and so instead of troubleshooting that service, I had
a closer look at the FreeIPA instance.
2. When connected to the FreeIPA instance, and issuing 'ipa
user-status username', the following error is returned:

ipa: ERROR: cert validation failed for CN=CERT_CN_REDACTED,OU=Domain
Control Validated ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate
issuer has been marked as not trusted by the user.)
ipa: ERROR: cert validation failed for CN=CERT_CN_REDACTED,OU=Domain
Control Validated ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate
issuer has been marked as not trusted by the user.)
ipa: ERROR: cannot connect to Gettext('any of the configured servers',
domain='ipa', localedir=None): https://IPA1_FQDN_REDACTED/ipa/xml,
https://IPA2_FQDN_REDACTED/ipa/xml

Note that, CERT_CN_REDACTED is the *.domain.tld cert that has been
renewed. Of note is that, prior to the certificate update noted above,
this did work correctly, and would return the status of the user.

Further, when issuing 'ipa service restart' on the IPA instance, the
following is returned:

# service ipa restart
Restarting Directory Service
Shutting down dirsrv:
DIRSRV_REDACTED... [  OK  ]
Starting dirsrv:
DIRSRV_REDACTED...[21/Oct/2014:19:07:22 -0700] - SSL alert:
CERT_VerifyCertificateNow: verify certificate failed for cert
CERT_CN_REDACTED - GoDaddy.com, Inc. of family
cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8172
- Peer's certificate issuer has been marked as not trusted by the
user.)
   [  OK  ]
Restarting KDC Service
Stopping Kerberos 5 KDC:   [  OK  ]
Starting Kerberos 5 KDC:   [  OK  ]
Restarting KPASSWD Service
Stopping Kerberos 5 Admin Server:  [  OK  ]
Starting Kerberos 5 Admin Server:  [  OK  ]
Restarting MEMCACHE Service
Stopping ipa_memcached:[  OK  ]
Starting ipa_memcached:[  OK  ]
Restarting HTTP Service
Stopping httpd:[  OK  ]
Starting httpd:[  OK  ]
#

Can anyone instruct me as to what may be misconfigured? I assume this
is the root cause of LDAP via SSL not working correctly, but I'm not
quite sure how to verify that.
It is of note to say that the CA bundle (a chain of public keys
leading to a root, 3rd party CA) issued with the new certificate is
different from the previous certificate bundle. I know this as I have
records of the original certificate, key, bundle, and CSR. The CA
bundle issued with this new certificate is *different* from the CA
bundle used with the original certificate. As I have not provided, or
otherwise used, this new CA bundle when renewing the certificates in
FreeIPA, I suspect this is the root cause of the error, and so I ask
for help here.

---
Dragan Prostran

-- 
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] No result when trying to integrate a FreeBSD client with the FreeIPA server