Re: [Freeipa-users] IPA, autofs, kerberos

2016-01-04 Thread Rob Crittenden 
Cal Sawyer wrote:
> Hi
> 
> After getting autofs working using automountmaps in IPA, i've discovered
> that upon rebooting a client i have no automounts.  If i ssh into the
> client and obtain a ticket as admin, after restarting autofs (as root),
> I can once again see access automounted directories.  Until then, user
> logins which depend on network home mount consistently fail
> 
> Question is, how can this be made automatic on reboot?

Credentials are needed to do the mounts so it depends on what
credentials you want/need to use for that. What mounts are these that
require Kerberos, home directories or something else?

GSS-Proxy can do this unattended,
https://fedorahosted.org/gss-proxy/wiki/NFS

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] unable to effectively delete a replica agreement

2016-01-04 Thread Rob Crittenden 
Karl Forner wrote:
> I am running a master freeIPA called "ipa" in an adelton/freeipa-server
> (freeIPA 4.1.4).
> I am able to create a replica server "ipa2", still in an
> adelton/freeipa-server.
> 
> If I stop my ipa2 replica, and try to delete the replication agreement:
> 
> |%ipa-replica-manage del ipa2.example.com 
> --force -v|
> 
> It hangs forever.

How long is forever?

> If I run it using the --cleanup option, it seems to work.

That does other things.

> 
> But when I try to run again from scratch my replica, using the same
> name, I get:
> 
> Checking forwarders, please wait ...
> WARNING: DNS forwarder 10.9.70.7 does not return DNSSEC signatures in
> answers
> Please fix forwarder configuration to enable DNSSEC support.
> (For BIND 9 add directive "dnssec-enable yes;" to "options {}")
> WARNING: DNSSEC validation will be disabled
> Warning: skipping DNS resolution of host ipa2.example.com
> 
> Warning: skipping DNS resolution of host ipa.example.com
> 
> Using reverse zone(s) 0.17.172.in-addr.arpa.
> A replication agreement for this host already exists. It needs to be
> removed.
> Run this on the master that generated the info file:
> % ipa-replica-manage del ipa2.example.com 
> --force
> 
> On my master:
> # ipa-replica-manage list
> ipas.example.com: master
> ipa.example.com: master
> 
> I manually removed all DNS entries from the 3 zones mentioning ipa2. I
> can check in the web UI, using the search feature that ipa2 has no
> occurrence.
> 
> So I do not understand why the replica install thinks there's still a
> replication agreement.
> And I'd like to know:
> 1) why this command did not work
> 
> |ipa-replica-manage del ipa2.example.com 
> --force -v|

Because replication agreements are separate from IPA masters, DNS, etc.

> 
> 2) How could I manually effectively delete this agrrement left-over.
> 

To see the agreements on any given master:

$ ldapsearch -x -D 'cn=directory manager' -W -b
'cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config'

Use ldapdelete to delete the orphan one, or use something like Apache
Studio if you're uncomfortable on the CLI.

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] Avoid auto-setting krbpasswordexpiration to pwdpolicy?

2016-01-04 Thread Rob Crittenden 
Martin René Mortensen wrote:
> Hi,
> 
> I am setting up an LDAP connection from our Identity Management system
> which provisions our IPA servers with fresh users and groups.
> I set it up pretty nice so far, with some added privileges for change
> admin passwords and avoiding password resets.
> But when we create a brand new user with a password, IPA resets the
> krbPasswordExpiration to match the IPA password policy - but we have
> another policy in our central identity management which gets must get
> set at user create time.
> 
> So the question is:
> Is there any way I can avoid getting krbPasswordExpiration reset to
> match the password policy?

I assume you are binding via LDAP to manage the users in which case you
can use this to not automatically expire reset passwords:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#password-sync

> and a followup question:
> Is this the same with AD sync? passwords from AD gets synced, but
> expiration is determined by local password policies on the IPA servers?

You'd need to keep the password policies in sync between the two
systems. Once they are synced they are independent unless the password
is changed.

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] Failed upgrade to 4.2 via RHEL 7.2

2016-01-04 Thread Martin Basti 



On 23.12.2015 08:28, Brian Topping wrote:

Greetings all! Thanks for all the continued work on FreeIPA! :)

I saw that 4.2 made it to RHEL 7.2 and upgraded. Unfortunately, the 
system did not come up cleanly.


It seems to be some problem with the DNS server:


[root@ipa01 ~]# systemctl status named-pkcs11
● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with 
native PKCS#11
   Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service; 
disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2015-12-23 01:56:37 
EST; 4s ago
  Process: 16506 ExecStart=/usr/sbin/named-pkcs11 -u named 
$OPTIONS (code=exited, status=1/FAILURE)
  Process: 16503 ExecStartPre=/bin/bash -c if [ ! 
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf 
-z /etc/named.conf; else echo "Checking of zone files is disabled"; 
fi (code=exited, status=0/SUCCESS)


Dec 23 01:56:37 ipa01.example.com  
named-pkcs11[16509]: GSSAPI client step 2
Dec 23 01:56:37 ipa01.example.com  
named-pkcs11[16509]: LDAP error: Invalid credentials: 
SASL(-14): authorization failure: security flags do not match 
required: bind to LDAP server failed
Dec 23 01:56:37 ipa01.example.com  
named-pkcs11[16509]: couldn't establish connection in LDAP connection 
pool: permission denied
Dec 23 01:56:37 ipa01.example.com  
named-pkcs11[16509]: dynamic database 'ipa' configuration failed: 
permission denied
Dec 23 01:56:37 ipa01.example.com  
named-pkcs11[16509]: loading configuration: permission denied
Dec 23 01:56:37 ipa01.example.com  
named-pkcs11[16509]: exiting (due to fatal error)
Dec 23 01:56:37 ipa01.example.com  
systemd[1]: named-pkcs11.service: control process exited, 
code=exited status=1
Dec 23 01:56:37 ipa01.example.com  
systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with 
native PKCS#11.
Dec 23 01:56:37 ipa01.example.com  
systemd[1]: Unit named-pkcs11.service entered failed state.
Dec 23 01:56:37 ipa01.example.com  
systemd[1]: named-pkcs11.service failed.


https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart provides 
some good information. After manually starting 389, I was able to 
confirm that the LDAP credentials are able to retrieve the DNS tree with:


[root@ipa01 ~]# ldapsearch -H 
'ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket' 
 -Y GSSAPI -b 
'cn=dns,dc=example,dc=com' 


I was also able to confirm that I the named.keytab file is correct:

[root@ipa01 ~]# kinit -k -t /etc/named.keytab DNS/ipa01.example.com 


[root@ipa01 ~]# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_th1WCcV
Default principal: DNS/ipa01.example@example.com 



Valid starting   Expires  Service principal
12/23/2015 02:07:14  12/24/2015 02:07:14 
krbtgt/example@example.com 


I have disabled unencrypted binds to 389, but I read somewhere this 
evening this should not be an issue since passwords were being sent 
and the STARTTLS is always being used.


https://fedorahosted.org/freeipa/ticket/5232 seems to be related here, 
but I did the install on a healthy server, so I can't imagine that 
it's the same. I also don't see any recovery techniques listed here or 
in the issue that it links to at 
https://bugzilla.redhat.com/show_bug.cgi?id=1254412. I searched the 
list archives for this error and came up empty. The versions I have 
are as follows:



bind-license-9.9.4-29.el7_2.1.noarch
bind-libs-lite-9.9.4-29.el7_2.1.x86_64
bind-utils-9.9.4-29.el7_2.1.x86_64
bind-pkcs11-libs-9.9.4-29.el7_2.1.x86_64
bind-dyndb-ldap-8.0-1.el7.x86_64
bind-pkcs11-utils-9.9.4-29.el7_2.1.x86_64
bind-9.9.4-29.el7_2.1.x86_64
bind-pkcs11-9.9.4-29.el7_2.1.x86_64
bind-libs-9.9.4-29.el7_2.1.x86_64
ipa-python-4.2.0-15.el7.centos.3.x86_64
ipa-admintools-4.2.0-15.el7.centos.3.x86_64
sssd-ipa-1.13.0-40.el7_2.1.x86_64
ipa-client-4.2.0-15.el7.centos.3.x86_64
ipa-server-dns-4.2.0-15.el7.centos.3.x86_64
ipa-server-4.2.0-15.el7.centos.3.x86_64
python-libipa_hbac-1.13.0-40.el7_2.1.x86_64
libipa_hbac-1.13.0-40.el7_2.1.x86_64


I'm also attaching the ipaupgrade.log

Hopefully I am missing something simple here. Can anyone help?

Happy solstice!

Brian






Hello,

can you check your value of umask?
-- 
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] DNSSEC Question (KSK ZSK)

2016-01-04 Thread Petr Spacek 
On 29.12.2015 17:39, Martin Basti wrote:
> 
> 
> On 29.12.2015 14:30, Günther J. Niederwimmer wrote:
>> Hello,
>>
>> Is it possible to install a DSNSEC Master with my before created KSK ZSK?
>>
>> Background:
>>
>> I have installed a IPA Master on my System now I have change the Hardware and
>> make a new installation with new Hardware?
>>
>> I have only a backup from the Files in
>> /var/named/dyndb-ldap/ipa/master/example.com/keys/
>>
>> When I now enable a new DNSSEC Master create freeIPA new KSK ZSK for the
>> Domain ?
>>
>> Then I have to wait after the holidays to UPDATE the DS Record on my ISP :-(.
>>
>> Thanks for a answer,
>>
> I'm not sure if this is possible,
> 
> IPA uses openDNSSEC, and it needs softhsm database and database of keys
> metadata, which are not located in /var/named/...
> 
> New installation of DNSSEC master will create new keys.
> 
> My colleague is more familiar with bind-dyndb-ldap, but he will be available
> after holidays too.

We did not try import, so there is no 100 % certain answer.

In general, it should work if you create the zone in IPA first, then import
new keys into OpenDNSSEC using OpenDNSSEC's means, then delete keys generated
by IPA.

Let me repeat that it is not tested. I hope this helps.

-- 
Petr^2 Spacek

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

Re: [Freeipa-users] Cockpit integration part I - Single Sign On

2016-01-04 Thread Alexander Bokovoy 

On Mon, 04 Jan 2016, Alexander Bokovoy wrote:

On Mon, 04 Jan 2016, Marius Vollmer wrote:

Alexander Bokovoy  writes:


Thanks. I think we actually could do better by using gss-proxy -- if
only cockpit-ws would cooperate[1]. I'll file a bug


Thanks!


-- when cockpit-ws launches cockpit-session it doesn't pass anything
from the environment cockpit-ws was launched with.


It uses NULL as the envp argument, which means that cockpit-session
inherits the environment from cockpit-ws, no?

You're right.


cockpit-session itself calls clearenv() very early, and that is probably
the reason why GSS_USE_PROXY doesn't work.

https://github.com/cockpit-project/cockpit/blob/master/src/ws/session.c#L955

In that case adding GSS_USE_PROXY to env_names and moving restore of the
environment before the PAM processing would probably be a solution?

I've filed an issue to cockpit:
https://github.com/cockpit-project/cockpit/issues/3407

It is a bit more complicated due to cockpit-session fiddling with
setuid().
--
/ 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] Want faster user-add

2016-01-04 Thread Martin Kosek 
On 12/22/2015 03:25 PM, Daryl Fonseca-Holt wrote:
> 
> 
> On 12/22/15 08:09, Petr Vobornik wrote:
>> On 12/22/2015 10:24 AM, thierry bordaz wrote:
>>> On 12/21/2015 05:55 PM, Daryl Fonseca-Holt wrote:
 Hi all,

 Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core
 256-GB RAM Oracle x4470 M2.

 During our migration from NIS on Solaris 140,000+ accounts will be
 added. After tuning per the guides dbmon.sh shows no roevicts and we
 get high cache hit ratios.

 Per a previous discussion with the list the input is broken down into
 batches of less than 1,000 users and the default IPA group is changed
 before each batch. This helped greatly.

 Adding all the users takes many hours. Initially ipa user-add takes an
 average 2.3 seconds per user but degrades by the time there are
 140,000 users to an average 6.7 seconds per user.

 In tracing it appears that a significant portion of the time ipa
 user-add takes is not the add itself, it is the query at the end that
 displays the resulting user account. Is there any legit way to prevent
 this query?

 The length of time it takes to migrate is not a big concern. The
 concern is the start of the fall school term when we typically add
 approximately 1,300 accounts per hour during the registration period
 with our current system.

 All suggestions will be appreciated.

 Regards, Daryl

>>> Hi Daryl,
>>>
>>> I can reproduce similar trend of user-add becoming slower and slower.
>>>
>>> Now in my tests (etime=7s) the time was spent half by authentication and
>>> half by ADD and MOD (update of ipausers group). I agree there are many
>>> direct SRCH (~10) but they all seems to be rapid.
>>>
>>> I know that the vast majority of the time is spent in DS schema-compat
>>> plugin. Disabling it, during provisioning, reduce the duration by ~3.
>>> Now I do not know if it is a valid option to disable this plugin during
>>> provisioning.
>>>
>>> thanks
>>> thierry
>>
>> We must also distinguish performance on IPA 3.x (RHEL 6.x) and FreeIPA 
>> 4.2/4.3
>>
>> FreeIPA 4.2 got some performance improvements mostly related to group
>> membership handling.
>>
>> Improving user-add is one of primary goals for 4.4 release:
>> * https://fedorahosted.org/freeipa/ticket/5448
>>
>> There are couple issues tracked about plugins output (also planned to be
>> fixed in 4.4):
>> * https://fedorahosted.org/freeipa/ticket/5281
>> * https://fedorahosted.org/freeipa/ticket/5282
>> * https://fedorahosted.org/freeipa/ticket/4995
>>
>> You can try to call user-add with --raw options but it won't help much
>> because some parts ignore it. Other than that, there is not clean workaround.
>>
>> When user is added, the user_add typically:
>> * adds the user to ipadefaultprimarygroup
>> * converts manger dn to human friedly value (should not cause perf. issues)
>> * set description to magic value to cause generation of user private group
>> (calls user-mod)
>> * fetches password attributes and resolves ssh pub keys (does couple of
>> searches)
>>
>> An unsupported possibility - do on your own risk - is to remove these
>> operations from user_add post_callback in ipalib/plugins/user.py (around line
>> 535 on 6.7).
>>
>> Other thing which might help is to remove 'memberof' and 'memberofindirect'
>> values from default_attributes in user.py (~line 216). Note that it also
>> affects other user-* commands.
>>
>> All should be tried in testing environment.
>>
>> Another performance improvement is to call IPA API directly and use batch
>> command - with that it is possible to add e.g. 100 users with one call and
>> save some network calls.
>>
>> Example could be seen in this ugly script:
>> https://pvoborni.fedorapeople.org/scripts/ipa-generate-users.sh
> I did test with RHEL7 and IPA 4.2 and the performance was much better. We 
> don't
> have RHEL7 deployed yet so there are some issues with change management but we
> may have to revisit that.
> 
> I looked at changing the code but we can't end up with an unsupported product.
> We depend on our Red Hat support heavily for production. So I could speed up
> the migration from the NIS server but I won't be able to keep the optimization
> during day-to-day operation.
> 
> Thanks for the script. Ugly scripts are good learning examples because it's
> easy to see the real purpose without the distraction of frills.

Just for the record, higher performance of user-add and management interface
overall is one of the planned areas we want to focus on in next FreeIPA
version. As you noticed, some portion of performance improvements are done in
FreeIPA 4.2/RHEL-7.2, next are planned, so please stay tuned :-)

-- 
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] Want faster user-add

2016-01-04 Thread Martin Kosek 
On 12/22/2015 04:16 PM, Simo Sorce wrote:
> On Tue, 2015-12-22 at 10:24 +0100, thierry bordaz wrote:
>> On 12/21/2015 05:55 PM, Daryl Fonseca-Holt wrote:
>>> Hi all,
>>>
>>> Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core 
>>> 256-GB RAM Oracle x4470 M2.
>>>
>>> During our migration from NIS on Solaris 140,000+ accounts will be 
>>> added. After tuning per the guides dbmon.sh shows no roevicts and we 
>>> get high cache hit ratios.
>>>
>>> Per a previous discussion with the list the input is broken down into 
>>> batches of less than 1,000 users and the default IPA group is changed 
>>> before each batch. This helped greatly.
>>>
>>> Adding all the users takes many hours. Initially ipa user-add takes an 
>>> average 2.3 seconds per user but degrades by the time there are 
>>> 140,000 users to an average 6.7 seconds per user.
>>>
>>> In tracing it appears that a significant portion of the time ipa 
>>> user-add takes is not the add itself, it is the query at the end that 
>>> displays the resulting user account. Is there any legit way to prevent 
>>> this query?
>>>
>>> The length of time it takes to migrate is not a big concern. The 
>>> concern is the start of the fall school term when we typically add 
>>> approximately 1,300 accounts per hour during the registration period 
>>> with our current system.
>>>
>>> All suggestions will be appreciated.
>>>
>>> Regards, Daryl
>>>
>> Hi Daryl,
>>
>> I can reproduce similar trend of user-add becoming slower and slower.
>>
>> Now in my tests (etime=7s) the time was spent half by authentication and 
>> half by ADD and MOD (update of ipausers group). I agree there are many 
>> direct SRCH (~10) but they all seems to be rapid.
>>
>> I know that the vast majority of the time is spent in DS schema-compat 
>> plugin. Disabling it, during provisioning, reduce the duration by ~3.
>> Now I do not know if it is a valid option to disable this plugin during 
>> provisioning.
> 
> As long as the schema compat is not needed by users during the
> provisioning, turning it off is fine. All the contents are regenerated
> at startup anyway. So it can be re-enabled and the server restarted
> after the bulk provisioning is done.

+1. When provisioning users via "ipa migrate-ds" command, schema compat is
strongly suggested to be turned off too.

-- 
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] Queries on migrating nis netgroups

2016-01-04 Thread Martin Kosek 
On 12/22/2015 12:10 PM, Roderick Johnstone wrote:
> Hi
> 
> I'm migrating our nis environment to freeipa 4.2.0 on Redhat 7.
> 
> I need to have the netgroups set up in freeipa before migrating systems to be
> freeipa clients.
> 
> At this point I'm trying to understand the relationship between hostgroups and
> netgroups and whether I should just be using ipa netgroup-add and ipa
> netgroup-add-member commands or whether I should be using equivalent ipa
> hostgroup* commands.
> 
> Section 14.5.1 of the Redhat 7 Domain Identity Authentication and Policy Guide
> is telling me that I get a shadow netgroup for every hostgroup I create and
> that I can manage these netgroups with the "ipa-host-net-manage" command.
> 
> I don't see the ipa-host-net-manage command. There are
> ipa host* commands but these don't include ipa host-net* commands. What am I
> missing here?

Good catch, this is actually a doc bug. I filed a Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1295408

Netgroups normally simply mirror host groups, so you do not have to use
"netgroup-*" commands if you do not manage native netgroup.

> Also the ipa netgroup* commands don't seem to be able to manage the shadow
> netgroups so I'm currently unable to manipulate my shadow netgroups to eg
> change the nisdomain associated with them. How do I do that?

Shadow netgroups should be only manipulated by updating the source hostgroups,
AFAIK.

> Also it looks like I can't add non-ipa clients into hostgroups so presumable
> not into shadow netgroups either, so maybe this is a non-starter for me. Did I
> understand that correctly?

I personally do not have practical experience with netgroups, but it is true
that non-ipa clients cannot be added to host groups. Maybe Rob (CCed) as NIS
knowledgeable person knows more what is the best solution here.

I anyway tried to add externalHost to the shadow hostgroup via ldapmodify as DM
and it worked:

# ipa netgroup-show masters
  Netgroup name: masters
  Description: ipaNetgroup masters
  NIS domain name: rhel72
  External host: foo
  Member Hostgroup: masters

I am still unable to add membership as admin though:

# ipa netgroup-add-member masters --hosts foo2
ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the
'externalHost' attribute of entry 'cn=masters,cn=ng,cn=alt,dc=rhel72'.

Martin

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

Re: [Freeipa-users] IPA DS migration

2016-01-04 Thread Martin Kosek 
On 12/29/2015 08:36 PM, Sean Conley - US wrote:
> Hello,
> 
> I need to migrate the users from an existing IPA server to a new IPA server 
> on an isolated network.  It appears that “ipa migrate-ds” works only when 
> direct connection to source LDAP server is possible.  I have searched with no 
> success for a method that would be more like an LDIF-based migration.  These 
> servers are in different realms and so have different base DNs.  My hope is 
> that I could create an LDIF file from a query against the source server, 
> modify records to reflect the new base DN, copy result to destination server, 
> and import it there.
> 
> Can anyone direct me to some good resources or other recommendations to 
> accomplish this?
> 
> The source server in this case is CentOS 7 with FreeIPA v4.1.0.  The planned 
> destination server is RHEL 7 with FreeIPA v4.2.0.
> 
> Thanks much in advance!

Hello,

You are more or less looking for

http://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA

There are some tips there already, but FreeIPA itself do not have off-the-shelf
solution, yet.

-- 
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] Cockpit integration part I - Single Sign On

2016-01-04 Thread Alexander Bokovoy 

On Mon, 04 Jan 2016, Marius Vollmer wrote:

Alexander Bokovoy  writes:


Thanks. I think we actually could do better by using gss-proxy -- if
only cockpit-ws would cooperate[1]. I'll file a bug


Thanks!


-- when cockpit-ws launches cockpit-session it doesn't pass anything
from the environment cockpit-ws was launched with.


It uses NULL as the envp argument, which means that cockpit-session
inherits the environment from cockpit-ws, no?

You're right.


cockpit-session itself calls clearenv() very early, and that is probably
the reason why GSS_USE_PROXY doesn't work.

https://github.com/cockpit-project/cockpit/blob/master/src/ws/session.c#L955

In that case adding GSS_USE_PROXY to env_names and moving restore of the
environment before the PAM processing would probably be a solution?

--
/ 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] deny read Access to passwd for external users

2016-01-04 Thread Jakub Hrozek 

> On 17 Dec 2015, at 11:35, José Garcia  wrote:
> 
> Hi guys, merry christmas and happy new year.
> 
> I have a freeipa (4.1.0) server on a centos 7 machine and its working fine 
> even with active directory integration.
> 
> But I would like to know if is it possible to deny read access to certain  
> system configuration files and directories 
> within the server and on clients , such as /etc/passwd  for example.

Same as for any users - either with UNIX DAC file permissions or SELinux. There 
is really nothing special about IPA users with this respect.

btw The IPA users are not stored in /etc/passwd and in general the data in 
/etc/passwd is not sensitive.
> -- 
> Best Regards
> -- 
> 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] how to force switch to another kdc

2016-01-04 Thread Karl Forner 
Hello,

My freeipa master has crashed, and I have a replica running.
The problem is that I can not use anymore the webapps on my main server
which use a kerberos authentication since my server will not switch to the
kdc on my replica.

I remember that someone replied me on this list about that problem, but I'd
like to konw if there's something I can do besides rebooting my main server
?

freeipa 4.3

sssd 1.12.5-1 running on ubuntu 14.04

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

Re: [Freeipa-users] IPA, autofs, kerberos

2016-01-04 Thread Prasun Gera 
I would like to understand this better too. I'm not using kerberized NFS.
I'm using regular nfs for user home dirs as well as other mount points,
which used to work quite well with autofs + NIS. For the most part it works
fine with ipa too. However, I have occasionally faced problems with autofs
not working well on clients. In such cases, the only thing that has worked
is calling the ipa-automount uninstall script, and reinstalling it. Is this
indicative of stale sss cache values ?

On Tue, Jan 5, 2016 at 12:37 AM, Rob Crittenden  wrote:

> Cal Sawyer wrote:
> > Hi
> >
> > After getting autofs working using automountmaps in IPA, i've discovered
> > that upon rebooting a client i have no automounts.  If i ssh into the
> > client and obtain a ticket as admin, after restarting autofs (as root),
> > I can once again see access automounted directories.  Until then, user
> > logins which depend on network home mount consistently fail
> >
> > Question is, how can this be made automatic on reboot?
>
> Credentials are needed to do the mounts so it depends on what
> credentials you want/need to use for that. What mounts are these that
> require Kerberos, home directories or something else?
>
> GSS-Proxy can do this unattended,
> https://fedorahosted.org/gss-proxy/wiki/NFS
>
> 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
>
-- 
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] unable to effectively delete a replica agreement

2016-01-04 Thread Karl Forner 
>
> > It hangs forever.
>
> How long is forever?
>

officially it's about 15 mns. Do you mean that this delay could be expected
?


>
> > If I run it using the --cleanup option, it seems to work.
>
> That does other things.
>

and actually it did not really work.


>
> >
> > But when I try to run again from scratch my replica, using the same
> > name, I get:
> >
> > Checking forwarders, please wait ...
> > WARNING: DNS forwarder 10.9.70.7 does not return DNSSEC signatures in
> > answers
> > Please fix forwarder configuration to enable DNSSEC support.
> > (For BIND 9 add directive "dnssec-enable yes;" to "options {}")
> > WARNING: DNSSEC validation will be disabled
> > Warning: skipping DNS resolution of host ipa2.example.com
> > 
> > Warning: skipping DNS resolution of host ipa.example.com
> > 
> > Using reverse zone(s) 0.17.172.in-addr.arpa.
> > A replication agreement for this host already exists. It needs to be
> > removed.
> > Run this on the master that generated the info file:
> > % ipa-replica-manage del ipa2.example.com 
> > --force
> >
> > On my master:
> > # ipa-replica-manage list
> > ipas.example.com: master
> > ipa.example.com: master
> >
> > I manually removed all DNS entries from the 3 zones mentioning ipa2. I
> > can check in the web UI, using the search feature that ipa2 has no
> > occurrence.
> >
> > So I do not understand why the replica install thinks there's still a
> > replication agreement.
> > And I'd like to know:
> > 1) why this command did not work
> >
> > |ipa-replica-manage del ipa2.example.com 
> > --force -v|
>
> Because replication agreements are separate from IPA masters, DNS, etc.
>
> >
> > 2) How could I manually effectively delete this agrrement left-over.
> >
>
> To see the agreements on any given master:
>
> $ ldapsearch -x -D 'cn=directory manager' -W -b
> 'cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config'
>
> Use ldapdelete to delete the orphan one, or use something like Apache
> Studio if you're uncomfortable on the CLI.
>
> 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] Using 3rd party certificates for HTTP/LDAP

2016-01-04 Thread Jan Cholasta 

Hi Peter,

On 21.12.2015 17:43, Peter Pakos wrote:

Hi,

I tried to install a wildcard SSL certificate for HTTP/LDAP in our
FreeIPA 4.1 (Centos 7.1) installation by following instructions from
wiki page at
http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP:


Unfortunately ipa-server-certinstall is currently broken. We plan to fix 
it some day, see  and 
.




# ipa-server-certinstall -w -d shdc01.ipa.wandisco.com.pem
Directory Manager password:
Enter private key unlock password:
Command /usr/bin/certutil' '-d' '/etc/httpd/alias' '-D' '-n'
'Server-Cert returned non-zero exit status 255

After this I was unable to start httpd service, error_log revealed the
following error messages:

[Wed Nov 25 18:15:44.262751 2015] [:error] [pid 22124] Certificate not
found: 'Server-Cert'

In order to resurrect the service I had to change NSSNickname in
/etc/httpd/conf.d/nss.conf to match the new certificate's nickname.

Although the httpd service started, I couldn't get into Authentication
tab in FreeIPA UI - I kept getting the following error message: "Unable
to communicate with CMS (Service Unavailable)".

[root@shdc01 ~]# yum list installed | grep ipa-server
ipa-server.x86_64 4.1.0-18.el7.centos.4 @updates

[root@shdc01 ~]# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)

At this point I was forced to restore our FreeIPA installation from a
snapshot as I wasn't able to fix it (I got some useful hints from
#freeipa Freenode channel however we still didn't manage to fully
resurrect the server).

My question is, what is the correct way of installing a 3rd party
certificate for HTTP/LDAP that will actually work?


1. Install the CA certificate chain of the issuer of the 3rd party 
certificate to IPA using "ipa-cacert-manage install"


2. Run "ipa-certupdate" to update CA certificate related IPA configuration.

3. Manually import the server certificate into the 
/etc/dirsrv/slapd-REALM NSS database, configure the correct nickname in 
LDAP in the nsSSLPersonalitySSL attribute of 
cn=RSA,cn=encryption,cn=config and restart DS.


4. Manually import the server certificate into the /etc/httpd/alias NSS 
database, configure the correct nickname in /etc/httpd/conf.d/nss.conf 
using the NSSNickname directive and restart httpd.




Many thanks in advance.

BTW, I also added a comment describing this problem to the ticket at
https://fedorahosted.org/freeipa/ticket/5496.


Honza

--
Jan Cholasta

--
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 4.x + CentOS 6.4

2016-01-04 Thread Martin Kosek 
On 01/03/2016 01:32 PM, Alexander Bokovoy wrote:
> On Wed, 23 Dec 2015, fvende@orange.com wrote:
>> Hi,
>>
>> Do you know the compatibility between the different "FreeIPA 4"
>> versions and CentOS 6.4, please ?  I have tried to get the information
>> but I don't have a clear response to this question.
> CentOS 6 clients can be enrolled into FreeIPA 4.x deployments.
> 
> CentOS 6 server cannot be used as a FreeIPA 4.x master.

To clarify even more, FreeIPA 4.x clients can work as clients with CentOS 6
server, except "ipa" management tool.

More on:
http://www.freeipa.org/page/Client#Compatibility

-- 
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] Using 3rd party certificates for HTTP/LDAP

2016-01-04 Thread Peter Pakos 

Hi Jan,

On 04/01/2016 12:44, Jan Cholasta wrote:


1. Install the CA certificate chain of the issuer of the 3rd party
certificate to IPA using "ipa-cacert-manage install"

2. Run "ipa-certupdate" to update CA certificate related IPA

configuration.


3. Manually import the server certificate into the
/etc/dirsrv/slapd-REALM NSS database, configure the correct nickname in
LDAP in the nsSSLPersonalitySSL attribute of
cn=RSA,cn=encryption,cn=config and restart DS.

4. Manually import the server certificate into the /etc/httpd/alias NSS
database, configure the correct nickname in /etc/httpd/conf.d/nss.conf
using the NSSNickname directive and restart httpd.


Would it be the same procedure for FreIPA 4.2 shipped with Centos 7.2?

TIA

--
Kind regards,
 Peter Pakos

--
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] Using 3rd party certificates for HTTP/LDAP

2016-01-04 Thread Jan Cholasta 

On 4.1.2016 14:10, Peter Pakos wrote:

Hi Jan,

On 04/01/2016 12:44, Jan Cholasta wrote:


1. Install the CA certificate chain of the issuer of the 3rd party
certificate to IPA using "ipa-cacert-manage install"

2. Run "ipa-certupdate" to update CA certificate related IPA

configuration.


3. Manually import the server certificate into the
/etc/dirsrv/slapd-REALM NSS database, configure the correct nickname in
LDAP in the nsSSLPersonalitySSL attribute of
cn=RSA,cn=encryption,cn=config and restart DS.

4. Manually import the server certificate into the /etc/httpd/alias NSS
database, configure the correct nickname in /etc/httpd/conf.d/nss.conf
using the NSSNickname directive and restart httpd.


Would it be the same procedure for FreIPA 4.2 shipped with Centos 7.2?


Yes.

--
Jan Cholasta

--
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] Cockpit integration part I - Single Sign On

2016-01-04 Thread Marius Vollmer 
Alexander Bokovoy  writes:

> Thanks. I think we actually could do better by using gss-proxy -- if
> only cockpit-ws would cooperate[1]. I'll file a bug

Thanks!

> -- when cockpit-ws launches cockpit-session it doesn't pass anything
> from the environment cockpit-ws was launched with.

It uses NULL as the envp argument, which means that cockpit-session
inherits the environment from cockpit-ws, no?

cockpit-session itself calls clearenv() very early, and that is probably
the reason why GSS_USE_PROXY doesn't work.

https://github.com/cockpit-project/cockpit/blob/master/src/ws/session.c#L955

-- 
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] Failed upgrade to 4.2 via RHEL 7.2

2016-01-04 Thread Petr Spacek 
On 4.1.2016 10:48, Martin Basti wrote:
> 
>> [root@ipa01 ~]# kinit -k -t /etc/named.keytab DNS/ipa01.example.com
>> 
>> [root@ipa01 ~]# klist
>> Ticket cache: KEYRING:persistent:0:krb_ccache_th1WCcV
>> Default principal: DNS/ipa01.example@example.com
>> 
>>
>> Valid starting   Expires  Service principal
>> 12/23/2015 02:07:14  12/24/2015 02:07:14 krbtgt/example@example.com
>> 
> 
> I have disabled unencrypted binds to 389, but I read somewhere this evening
> this should not be an issue since passwords were being sent and the STARTTLS
> is always being used.

Please write down *exact* configuration changes you did.

Generally named-pkcs11 is using GSSAPI and not TLS, so it will not work if you
enforced TLS on all connections.

-- 
Petr^2 Spacek

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

Re: [Freeipa-users] Want faster user-add

2016-01-04 Thread thierry bordaz 

On 01/04/2016 01:03 PM, Martin Kosek wrote:

On 12/22/2015 04:16 PM, Simo Sorce wrote:

On Tue, 2015-12-22 at 10:24 +0100, thierry bordaz wrote:

On 12/21/2015 05:55 PM, Daryl Fonseca-Holt wrote:

Hi all,

Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core
256-GB RAM Oracle x4470 M2.

During our migration from NIS on Solaris 140,000+ accounts will be
added. After tuning per the guides dbmon.sh shows no roevicts and we
get high cache hit ratios.

Per a previous discussion with the list the input is broken down into
batches of less than 1,000 users and the default IPA group is changed
before each batch. This helped greatly.

Adding all the users takes many hours. Initially ipa user-add takes an
average 2.3 seconds per user but degrades by the time there are
140,000 users to an average 6.7 seconds per user.

In tracing it appears that a significant portion of the time ipa
user-add takes is not the add itself, it is the query at the end that
displays the resulting user account. Is there any legit way to prevent
this query?

The length of time it takes to migrate is not a big concern. The
concern is the start of the fall school term when we typically add
approximately 1,300 accounts per hour during the registration period
with our current system.

All suggestions will be appreciated.

Regards, Daryl


Hi Daryl,

I can reproduce similar trend of user-add becoming slower and slower.

Now in my tests (etime=7s) the time was spent half by authentication and
half by ADD and MOD (update of ipausers group). I agree there are many
direct SRCH (~10) but they all seems to be rapid.

I know that the vast majority of the time is spent in DS schema-compat
plugin. Disabling it, during provisioning, reduce the duration by ~3.
Now I do not know if it is a valid option to disable this plugin during
provisioning.

As long as the schema compat is not needed by users during the
provisioning, turning it off is fine. All the contents are regenerated
at startup anyway. So it can be re-enabled and the server restarted
after the bulk provisioning is done.

+1. When provisioning users via "ipa migrate-ds" command, schema compat is
strongly suggested to be turned off too.
For information, accelerating user-add is investigated under 
https://fedorahosted.org/freeipa/ticket/5448.
Schema-compat has a significant impact on ldap ADD and MOD done during 
user-add. Now appropriate setting of scope of others plugins (dna, 
memberof, uniqueness, uuid...) shows that ADD can be reduced by 10 and 
MOD by 2, this even if schema-compat is still enabled.

So there are also possible improvements in plugin tuning.
-- 
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] Fwd: NetworkError : invalid continuation byte with utf8 codec

2016-01-04 Thread Domineaux Philippe 
Hello,

Happy new year.

So the content of my /etc/locale.conf :

LANG="fr_FR.UTF-8"

-- Forwarded message --
From: Fraser Tweedale 
Date: 2015-12-23 5:11 GMT+01:00
Subject: Re: [Freeipa-users] NetworkError : invalid continuation byte with
utf8 codec
To: Gmail 
Cc: freeipa-users@redhat.com


On Tue, Dec 22, 2015 at 08:39:09AM +0100, Gmail wrote:
> Here are the files you ask for:
>
Thank you.  I see Tomcat is running in an fr_FR locale. Could you
also provide contents of `/etc/locale.conf'?

Cheers,
Fraser

>
>
> Le 22 décembre 2015 à 02:30:06, Fraser Tweedale (ftwee...@redhat.com) a
écrit:
>
> On Mon, Dec 21, 2015 at 05:29:01PM +0100, Gmail wrote:
> > Hi all,
> >
> > When trying to install on a fresh new Centos 7 I’ve got this error :
> >
> > 2015-12-21T16:04:44Z DEBUG The ipa-server-install command failed,
exception: NetworkError: cannot connect to '
https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't
decode byte 0xea in position 13: invalid continuation byte
> > 2015-12-21T16:04:44Z ERROR cannot connect to '
https://freeipa.ipa.local:8443/ca/rest/profiles/raw': 'utf8' codec can't
decode byte 0xea in position 13: invalid continuation byte
> >
> > My freeipa-server version is :  4.2.0
> > I’m running a Centos 3.10.0-327.3.1.el7.x86_64
> >
> > Any idea of what goes wrong?
> >
> Thanks for reporting. I have not seen this error before. Could you
> please include the following log files and I will take a closer
> look:
>
> /var/log/ipaserver-install.log
> /var/log/pki/pki-tomcat/ca/debug
>
> Cheers,
> Fraser
-- 
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] Queries on migrating nis netgroups

2016-01-04 Thread Martin Kosek 
On 01/04/2016 10:41 PM, Rob Crittenden wrote:
> Martin Kosek wrote:
...
>> I anyway tried to add externalHost to the shadow hostgroup via ldapmodify as 
>> DM
>> and it worked:
>>
>> # ipa netgroup-show masters
>>   Netgroup name: masters
>>   Description: ipaNetgroup masters
>>   NIS domain name: rhel72
>>   External host: foo
>>   Member Hostgroup: masters
>>
>> I am still unable to add membership as admin though:
>>
>> # ipa netgroup-add-member masters --hosts foo2
>> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the
>> 'externalHost' attribute of entry 'cn=masters,cn=ng,cn=alt,dc=rhel72'.
> 
> That is the right way to do it. Unknown hosts to IPA are marked as
> "external" and stored separately. Just be aware that you can put
> anything in there so beware of typoes.
> 
> This command works fine for me using IPA using ipa-server-4.2.0-15.el7
> so I'm not sure where the permission bug lies.

Did you try it on native netgroup (added via netgroup-add) or hostgroup shadow
group? As it works for me on native netgroups, but not on shadow netgroups,
where I can only add the external host with as DM.

-- 
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] SSSD to IPA connection?

2016-01-04 Thread Jakub Hrozek 
On Mon, Jan 04, 2016 at 09:17:39AM -0800, Janelle wrote:
> When this happens - it stops accepting logins for any of my users.

Can you please generate logs when this happens? I suspect sssd might go
offline for one reason or another..

> I have to restart SSSD to get it to work again.

..and a restart would re-set the offline status.

> And it is just kind of random when this happens.
> How can a STATUS command sent to SSSD show a wrong password?

I think krb5_child logs some of its errors to syslog, perhaps we
shouldn't log preauth failed, though.

> 
> 
> ~J
> 
> On 1/4/16 9:11 AM, Jakub Hrozek wrote:
> >On Mon, Jan 04, 2016 at 08:30:08AM -0800, Janelle wrote:
> >>Happy New Year everyone!
> >>
> >>I came across a couple of my servers having some strange connection problems
> >>and was wondering if anyone else has seen this or know what might cause it?
> >>This is IPA 4.1.4 and client on RHEL 7.1. When you look at the status, for
> >>some reason, SSSD has lost contact with the servers, and a restart is
> >>required. What I don't understand is what this "Preauth" failure is?
> >>
> >>Ideas?
> >>~Janelle
> >>
> >>Redirecting to /bin/systemctl status  sssd.service
> >>sssd.service - System Security Services Daemon
> >>Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
> >>   Drop-In: /etc/systemd/system/sssd.service.d
> >>└─journal.conf
> >>Active: active (running) since Sat 2015-12-12 07:41:55 EST; 2 weeks 4
> >>days ago
> >>   Process: 24482 ExecStart=/usr/sbin/sssd -D -f (code=exited,
> >>status=0/SUCCESS)
> >>  Main PID: 24483 (sssd)
> >>CGroup: /system.slice/sssd.service
> >>├─24483 /usr/sbin/sssd -D -f
> >>├─24484 /usr/libexec/sssd/sssd_be --domain example.com --uid 0
> >>--gid 0 --debug-to-files
> >>├─24485 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0
> >>--debug-to-files
> >>├─24486 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0
> >>--debug-to-files
> >>├─24487 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0
> >>--debug-to-files
> >>└─24488 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0
> >>--debug-to-files
> >>
> >>Jan 01 07:55:24 client.example.com [sssd[krb5_child[10456]]][10456]:
> >>Preauthentication failed
> >>Jan 01 07:56:07 client.example.com [sssd[krb5_child[10464]]][10464]:
> >>Preauthentication failed
> >>Jan 01 07:57:16 client.example.com [sssd[krb5_child[10471]]][10471]:
> >>Preauthentication failed
> >Preauthentication failed means more or less wrong password, but since
> >the message is from krb5_child, I guess it's during user login.
> >
> >What exactly is not working?
> >
> >>Jan 01 08:10:48 client.example.com sssd_be[12345]: GSSAPI client step 1
> >>Jan 01 08:10:48 client.example.com sssd_be[12345]: GSSAPI client step 1
> >>Jan 01 08:10:49 client.example.com sssd_be[12345]: GSSAPI client step 1
> >>Jan 01 08:10:49 client.example.com sssd_be[12345]: GSSAPI client step 2
> >>Jan 01 08:20:10 client.example.com [sssd[krb5_child[10538]]][10538]:
> >>Preauthentication failed
> >>Jan 01 08:20:29 client.example.com [sssd[krb5_child[10541]]][10541]:
> >>Preauthentication failed
> >>Jan 01 08:20:48 client.example.com [sssd[krb5_child[10596]]][10596]:
> >>Preauthentication failed
> >>
> >>-- 
> >>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

-- 
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 server in Docker containers -- upcoming changes

2016-01-04 Thread Jan Pazdziora 
On Thu, Dec 17, 2015 at 11:30:53AM +0100, Jan Pazdziora wrote:
> 
> if you are running FreeIPA servers in containers, you might want to
> be aware of a change that is coming -- in branch master-systemd of
> 
>   https://github.com/adelton/docker-freeipa
> 
> we run the FreeIPA services via native systemd in the container,
> instead of the emulation of systemctl that the current branches and
> images use. That requires new option to be passed to the docker run

If you've tried the systemd-based installation, you might have noticed
that the output you get from docker run is different from the old
ways. Instead of the ipa-server-install output

http://fpaste.org/306943/

you will see systemd output listing its operations on services, namely
many starts and stops:

http://fpaste.org/306944/

The old output definitely made it easier to see what is happening,
the new output is closer to what you'd expect from IPA server on
a machine.

Similar change happens during subsequent start or upgrade from older
version of the data volome.

It should be pretty easy to bring the ipa-server-install output
back to the systemd-based containers but I wanted to check with you,
FreeIPA admins and users, to see what you'd expect and what you
prefer. Do you have a preference, or suggestion for something
completely different?

Thank you,

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

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

Re: [Freeipa-users] SSSD to IPA connection?

2016-01-04 Thread Jakub Hrozek 
On Mon, Jan 04, 2016 at 08:30:08AM -0800, Janelle wrote:
> Happy New Year everyone!
> 
> I came across a couple of my servers having some strange connection problems
> and was wondering if anyone else has seen this or know what might cause it?
> This is IPA 4.1.4 and client on RHEL 7.1. When you look at the status, for
> some reason, SSSD has lost contact with the servers, and a restart is
> required. What I don't understand is what this "Preauth" failure is?
> 
> Ideas?
> ~Janelle
> 
> Redirecting to /bin/systemctl status  sssd.service
> sssd.service - System Security Services Daemon
>Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
>   Drop-In: /etc/systemd/system/sssd.service.d
>└─journal.conf
>Active: active (running) since Sat 2015-12-12 07:41:55 EST; 2 weeks 4
> days ago
>   Process: 24482 ExecStart=/usr/sbin/sssd -D -f (code=exited,
> status=0/SUCCESS)
>  Main PID: 24483 (sssd)
>CGroup: /system.slice/sssd.service
>├─24483 /usr/sbin/sssd -D -f
>├─24484 /usr/libexec/sssd/sssd_be --domain example.com --uid 0
> --gid 0 --debug-to-files
>├─24485 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0
> --debug-to-files
>├─24486 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0
> --debug-to-files
>├─24487 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0
> --debug-to-files
>└─24488 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0
> --debug-to-files
> 
> Jan 01 07:55:24 client.example.com [sssd[krb5_child[10456]]][10456]:
> Preauthentication failed
> Jan 01 07:56:07 client.example.com [sssd[krb5_child[10464]]][10464]:
> Preauthentication failed
> Jan 01 07:57:16 client.example.com [sssd[krb5_child[10471]]][10471]:
> Preauthentication failed

Preauthentication failed means more or less wrong password, but since
the message is from krb5_child, I guess it's during user login.

What exactly is not working?

> Jan 01 08:10:48 client.example.com sssd_be[12345]: GSSAPI client step 1
> Jan 01 08:10:48 client.example.com sssd_be[12345]: GSSAPI client step 1
> Jan 01 08:10:49 client.example.com sssd_be[12345]: GSSAPI client step 1
> Jan 01 08:10:49 client.example.com sssd_be[12345]: GSSAPI client step 2
> Jan 01 08:20:10 client.example.com [sssd[krb5_child[10538]]][10538]:
> Preauthentication failed
> Jan 01 08:20:29 client.example.com [sssd[krb5_child[10541]]][10541]:
> Preauthentication failed
> Jan 01 08:20:48 client.example.com [sssd[krb5_child[10596]]][10596]:
> Preauthentication failed
> 
> -- 
> 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] Queries on migrating nis netgroups

2016-01-04 Thread Rob Crittenden 
Martin Kosek wrote:
> On 12/22/2015 12:10 PM, Roderick Johnstone wrote:
>> Hi
>>
>> I'm migrating our nis environment to freeipa 4.2.0 on Redhat 7.
>>
>> I need to have the netgroups set up in freeipa before migrating systems to be
>> freeipa clients.
>>
>> At this point I'm trying to understand the relationship between hostgroups 
>> and
>> netgroups and whether I should just be using ipa netgroup-add and ipa
>> netgroup-add-member commands or whether I should be using equivalent ipa
>> hostgroup* commands.
>>
>> Section 14.5.1 of the Redhat 7 Domain Identity Authentication and Policy 
>> Guide
>> is telling me that I get a shadow netgroup for every hostgroup I create and
>> that I can manage these netgroups with the "ipa-host-net-manage" command.
>>
>> I don't see the ipa-host-net-manage command. There are
>> ipa host* commands but these don't include ipa host-net* commands. What am I
>> missing here?
> 
> Good catch, this is actually a doc bug. I filed a Bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=1295408
> 
> Netgroups normally simply mirror host groups, so you do not have to use
> "netgroup-*" commands if you do not manage native netgroup.
> 
>> Also the ipa netgroup* commands don't seem to be able to manage the shadow
>> netgroups so I'm currently unable to manipulate my shadow netgroups to eg
>> change the nisdomain associated with them. How do I do that?
> 
> Shadow netgroups should be only manipulated by updating the source hostgroups,
> AFAIK.

It depends on what you want. If the netgroup is a mirror of a hostgroup
then you have to manage it via the hostgroup commands and you don't
control the NIS domain. If you need more control or a real netgroup, use
the netgroup commands. But I'll note that we've done little to no
testing of the IPA fake NIS server providing multiple NIS domains. It
should work for netgroup but I think for other maps it won't because
only maps for the IPA domain are created by default.

>> Also it looks like I can't add non-ipa clients into hostgroups so presumable
>> not into shadow netgroups either, so maybe this is a non-starter for me. Did 
>> I
>> understand that correctly?
> 
> I personally do not have practical experience with netgroups, but it is true
> that non-ipa clients cannot be added to host groups. Maybe Rob (CCed) as NIS
> knowledgeable person knows more what is the best solution here.
> 
> I anyway tried to add externalHost to the shadow hostgroup via ldapmodify as 
> DM
> and it worked:
> 
> # ipa netgroup-show masters
>   Netgroup name: masters
>   Description: ipaNetgroup masters
>   NIS domain name: rhel72
>   External host: foo
>   Member Hostgroup: masters
> 
> I am still unable to add membership as admin though:
> 
> # ipa netgroup-add-member masters --hosts foo2
> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the
> 'externalHost' attribute of entry 'cn=masters,cn=ng,cn=alt,dc=rhel72'.

That is the right way to do it. Unknown hosts to IPA are marked as
"external" and stored separately. Just be aware that you can put
anything in there so beware of typoes.

This command works fine for me using IPA using ipa-server-4.2.0-15.el7
so I'm not sure where the permission bug lies.

rob
rob

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

[Freeipa-users] SSSD to IPA connection?

2016-01-04 Thread Janelle 

Happy New Year everyone!

I came across a couple of my servers having some strange connection 
problems and was wondering if anyone else has seen this or know what 
might cause it? This is IPA 4.1.4 and client on RHEL 7.1. When you look 
at the status, for some reason, SSSD has lost contact with the servers, 
and a restart is required. What I don't understand is what this 
"Preauth" failure is?


Ideas?
~Janelle

Redirecting to /bin/systemctl status  sssd.service
sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
  Drop-In: /etc/systemd/system/sssd.service.d
   └─journal.conf
   Active: active (running) since Sat 2015-12-12 07:41:55 EST; 2 weeks 
4 days ago
  Process: 24482 ExecStart=/usr/sbin/sssd -D -f (code=exited, 
status=0/SUCCESS)

 Main PID: 24483 (sssd)
   CGroup: /system.slice/sssd.service
   ├─24483 /usr/sbin/sssd -D -f
   ├─24484 /usr/libexec/sssd/sssd_be --domain example.com --uid 
0 --gid 0 --debug-to-files
   ├─24485 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 
--debug-to-files
   ├─24486 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 
--debug-to-files
   ├─24487 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 
--debug-to-files
   └─24488 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 
--debug-to-files


Jan 01 07:55:24 client.example.com [sssd[krb5_child[10456]]][10456]: 
Preauthentication failed
Jan 01 07:56:07 client.example.com [sssd[krb5_child[10464]]][10464]: 
Preauthentication failed
Jan 01 07:57:16 client.example.com [sssd[krb5_child[10471]]][10471]: 
Preauthentication failed

Jan 01 08:10:48 client.example.com sssd_be[12345]: GSSAPI client step 1
Jan 01 08:10:48 client.example.com sssd_be[12345]: GSSAPI client step 1
Jan 01 08:10:49 client.example.com sssd_be[12345]: GSSAPI client step 1
Jan 01 08:10:49 client.example.com sssd_be[12345]: GSSAPI client step 2
Jan 01 08:20:10 client.example.com [sssd[krb5_child[10538]]][10538]: 
Preauthentication failed
Jan 01 08:20:29 client.example.com [sssd[krb5_child[10541]]][10541]: 
Preauthentication failed
Jan 01 08:20:48 client.example.com [sssd[krb5_child[10596]]][10596]: 
Preauthentication failed


--
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] SSSD to IPA connection?

2016-01-04 Thread Janelle 

When this happens - it stops accepting logins for any of my users.
I have to restart SSSD to get it to work again.
And it is just kind of random when this happens.
How can a STATUS command sent to SSSD show a wrong password?


~J

On 1/4/16 9:11 AM, Jakub Hrozek wrote:

On Mon, Jan 04, 2016 at 08:30:08AM -0800, Janelle wrote:

Happy New Year everyone!

I came across a couple of my servers having some strange connection problems
and was wondering if anyone else has seen this or know what might cause it?
This is IPA 4.1.4 and client on RHEL 7.1. When you look at the status, for
some reason, SSSD has lost contact with the servers, and a restart is
required. What I don't understand is what this "Preauth" failure is?

Ideas?
~Janelle

Redirecting to /bin/systemctl status  sssd.service
sssd.service - System Security Services Daemon
Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Drop-In: /etc/systemd/system/sssd.service.d
└─journal.conf
Active: active (running) since Sat 2015-12-12 07:41:55 EST; 2 weeks 4
days ago
   Process: 24482 ExecStart=/usr/sbin/sssd -D -f (code=exited,
status=0/SUCCESS)
  Main PID: 24483 (sssd)
CGroup: /system.slice/sssd.service
├─24483 /usr/sbin/sssd -D -f
├─24484 /usr/libexec/sssd/sssd_be --domain example.com --uid 0
--gid 0 --debug-to-files
├─24485 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0
--debug-to-files
├─24486 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0
--debug-to-files
├─24487 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0
--debug-to-files
└─24488 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0
--debug-to-files

Jan 01 07:55:24 client.example.com [sssd[krb5_child[10456]]][10456]:
Preauthentication failed
Jan 01 07:56:07 client.example.com [sssd[krb5_child[10464]]][10464]:
Preauthentication failed
Jan 01 07:57:16 client.example.com [sssd[krb5_child[10471]]][10471]:
Preauthentication failed

Preauthentication failed means more or less wrong password, but since
the message is from krb5_child, I guess it's during user login.

What exactly is not working?


Jan 01 08:10:48 client.example.com sssd_be[12345]: GSSAPI client step 1
Jan 01 08:10:48 client.example.com sssd_be[12345]: GSSAPI client step 1
Jan 01 08:10:49 client.example.com sssd_be[12345]: GSSAPI client step 1
Jan 01 08:10:49 client.example.com sssd_be[12345]: GSSAPI client step 2
Jan 01 08:20:10 client.example.com [sssd[krb5_child[10538]]][10538]:
Preauthentication failed
Jan 01 08:20:29 client.example.com [sssd[krb5_child[10541]]][10541]:
Preauthentication failed
Jan 01 08:20:48 client.example.com [sssd[krb5_child[10596]]][10596]:
Preauthentication failed

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