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 
>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 :
>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 ==
* Director

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=', and that works with FreeIPA 
3.3. But in FreeIPA v4 host groups get in 'cn=ng,cn=compat,dc='. 
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 :

> 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 :
> 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.
>
> Thanks,
> John DeSantis
>
>
> 2014-10-22 15:49 GMT-04:00 Rob Crittenden :
>> 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.
>>
>> 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.
>>

 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 file

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=', and that works with FreeIPA 
3.3. But in FreeIPA v4 host groups get in 
'cn=ng,cn=compat,dc='. 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,

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.

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 :

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 :

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 rep

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


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

[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 Sumit Bose

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

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


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 :

> 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


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 :

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

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

> 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=', 
>and that works with FreeIPA 3.3. But in FreeIPA v4 host groups get in 
>'cn=ng,cn=compat,dc='. 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 :
>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] Synchronization Agreements between FreeIPA and AD

2014-10-23 Thread Dmitri Pal


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 
" (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]


Can you connect from this replica to AD using ldapsearch?



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


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=', and that works with FreeIPA
3.3. But in FreeIPA v4 host groups get in
'cn=ng,cn=compat,dc='. 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 
" (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]


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  
написал:п>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=', and that works with FreeIPA
>>>3.3. But in FreeIPA v4 host groups get in
>>>'cn=ng,cn=compat,dc='. 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 sc

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 :

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

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  > 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 " - 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 " - my
user shows up in the group . Odd.

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

-M

On Thu, Oct 23, 2014 at 5:15 PM, Michael Lasevich 
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 " - 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 :
> >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 
> >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