Re: [Freeipa-users] Queries on migrating nis netgroups

[Rob Crittenden]

Martin Kosek wrote:
> On 01/05/2016 04:24 PM, Rob Crittenden wrote:
>> Martin Kosek wrote:
>>> 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.
>>>
>>
>> I didn't but I can reproduce it.
>>
>> It is probably due to this deny ACI:
>>
>> aci: (targetfilter = "(objectClass=mepManagedEntry)")(targetattr =
>> "*")(version 3.0; acl "Managed netgroups cannot be modified"; deny
>> (write) userdn = "ldap:///all;;)
> 
> Ah, good catch. I was suspecting something like that, I just did not know we
> went that far to create deny ACI.
> 
>> Not very nice behavior (and deny ACIs are icky).
>>
>> I guess the netgroup mod commands should look to see if it is a real
>> netgroup before trying to do a write and otherwise raise a more
>> reasonable error.
> 
> Potentially yes, although I do not see that as the most important part. I
> rather do not know how to solve Roderick's issue and add external hosts as 
> part
> of the shadow netgroups.
> 
> Currently, the only workaround is to create plain host/ghost entries for these
> non-ipa clients and use them in host groups.
> 

That or use real netgroups created via netgroup-add instead of
hostgroups. That is the only way to have control over the advertised NIS
domain in the triple anyway.

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

[Martin Kosek]

On 01/05/2016 04:24 PM, Rob Crittenden wrote:
> Martin Kosek wrote:
>> 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.
>>
> 
> I didn't but I can reproduce it.
> 
> It is probably due to this deny ACI:
> 
> aci: (targetfilter = "(objectClass=mepManagedEntry)")(targetattr =
> "*")(version 3.0; acl "Managed netgroups cannot be modified"; deny
> (write) userdn = "ldap:///all;;)

Ah, good catch. I was suspecting something like that, I just did not know we
went that far to create deny ACI.

> Not very nice behavior (and deny ACIs are icky).
> 
> I guess the netgroup mod commands should look to see if it is a real
> netgroup before trying to do a write and otherwise raise a more
> reasonable error.

Potentially yes, although I do not see that as the most important part. I
rather do not know how to solve Roderick's issue and add external hosts as part
of the shadow netgroups.

Currently, the only workaround is to create plain host/ghost entries for these
non-ipa clients and use them in host groups.

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

[bahan w]

Hello.

I have some questions related to this point :
1. On a RHEL6.6, may I install the package ipa-client 4.x and enroll to an
ipa server 4.x located on a RHEL7 ? May you remind me the version of sssd
embedded with ipa-client 4.x ?
2. The ipa-server 4.x can only be installed on RHEL7+, true/false ?

Best regards.

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

[Rob Crittenden]

Karl Forner wrote:
> 
> 
> >
> > It hangs forever.
> 
> How long is forever?
> 
> 
> officially it's about 15 mns. Do you mean that this delay could be
> expected ?

Forever is a measurement of patience. I'd have expected a timeout at
some point. To really diagnose things we'd probably need to instrument
ipa-replica-manage to find out where it is getting stuck.

> 
> 
> > If I run it using the --cleanup option, it seems to work.
> 
> That does other things.
> 
> 
> and actually it did not really work.

All cleanup does is remove the host as an IPA master. It does nothing
with agreements.

Did you find the agreement using the ldapsearch I proposed?

rob

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

[bahan w]

Thanks.

And for the ipa-client package ? Is it installable on Redhat 6.6 ?
Or is it only installable on Redhat 7.x ?

Best regards.

Bahan

On Tue, Jan 5, 2016 at 3:31 PM, Lukas Slebodnik  wrote:

> On (05/01/16 15:11), bahan w wrote:
> >Hello.
> >
> >I have some questions related to this point :
> >1. On a RHEL6.6, may I install the package ipa-client 4.x and enroll to an
> >ipa server 4.x located on a RHEL7 ? May you remind me the version of sssd
> >embedded with ipa-client 4.x ?
> rhel6.6 has ipa-client-3.0.0-47.el6 and sssd-1.11.x
> rhel6.7 has ipa-client-3.0.0-47.el6 and sssd-1.12.x
>
> and sssd-1.11+ works well with ipa-server 4.x
>
> >2. The ipa-server 4.x can only be installed on RHEL7+, true/false ?
> >
> true ( +fedora :-)
>
> 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 4.x + CentOS 6.4

[Lukas Slebodnik]

On (05/01/16 15:11), bahan w wrote:
>Hello.
>
>I have some questions related to this point :
>1. On a RHEL6.6, may I install the package ipa-client 4.x and enroll to an
>ipa server 4.x located on a RHEL7 ? May you remind me the version of sssd
>embedded with ipa-client 4.x ?
rhel6.6 has ipa-client-3.0.0-47.el6 and sssd-1.11.x
rhel6.7 has ipa-client-3.0.0-47.el6 and sssd-1.12.x

and sssd-1.11+ works well with ipa-server 4.x

>2. The ipa-server 4.x can only be installed on RHEL7+, true/false ?
>
true ( +fedora :-)

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

[Rob Crittenden]

Martin Kosek wrote:
> 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.
> 

I didn't but I can reproduce it.

It is probably due to this deny ACI:

aci: (targetfilter = "(objectClass=mepManagedEntry)")(targetattr =
"*")(version 3.0; acl "Managed netgroups cannot be modified"; deny
(write) userdn = "ldap:///all;;)

Not very nice behavior (and deny ACIs are icky).

I guess the netgroup mod commands should look to see if it is a real
netgroup before trying to do a write and otherwise raise a more
reasonable error.

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] how to force switch to another kdc

[Karl Forner]

Another piece of information:

the linux boxes are running ubuntu too, with the same configuration.
I have configured 2 dns servers, the first for my main freeipa server
(which is down), and rhe second for the replica.
After boot, the linux box can resolve addresses just fine, using the
secondary dns. But the box does not pick the kdc from the replica.

It seems to only use the cache, since when I do a klist, I have a ticked
expiring at 01/01/1970:
Valid starting   Expires  Service principal
01/01/1970 01:00:00  01/01/1970 01:00:00

If I do a kinit:
kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial
credentials

And once again, from a box just rebooted.

When I look at my /etc/krb5.conf, there's a kdc, master_kdc, and
admin_server set for my domain.
>From what I had understood, I thought they should be ignored, and that the
auto discovery should still happen.
Is that so ?

Thanks.



On Tue, Jan 5, 2016 at 12:16 AM, Karl Forner  wrote:

> 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] how to force switch to another kdc

[Alexander Bokovoy]

On Tue, 05 Jan 2016, Karl Forner wrote:

update:

modifying the /etc/krb5.conf, and replacing the name of my freeipa master
by the replica fixes the problem.
So that proves that the kdc is not picked up by discovery.

This implies you have explicit line stating the KDC address in your
krb5.conf. That means no DNS SRV record discovery will be done at all
because there is no need to discover anything.

Look at the Natxo's example in the other email.


--
/ 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] how to force switch to another kdc

[Karl Forner]

update:

modifying the /etc/krb5.conf, and replacing the name of my freeipa master
by the replica fixes the problem.
So that proves that the kdc is not picked up by discovery.

The problem is that my ubuntu box was enrolled using the ipa-client-install
script, and so should be properly configured.

Did I miss any critical option ?
What should the /etc/krb5.conf be like ?

Thanks.




On Tue, Jan 5, 2016 at 7:06 PM, Karl Forner  wrote:

> Another piece of information:
>
> the linux boxes are running ubuntu too, with the same configuration.
> I have configured 2 dns servers, the first for my main freeipa server
> (which is down), and rhe second for the replica.
> After boot, the linux box can resolve addresses just fine, using the
> secondary dns. But the box does not pick the kdc from the replica.
>
> It seems to only use the cache, since when I do a klist, I have a ticked
> expiring at 01/01/1970:
> Valid starting   Expires  Service principal
> 01/01/1970 01:00:00  01/01/1970 01:00:00
>
> If I do a kinit:
> kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting
> initial credentials
>
> And once again, from a box just rebooted.
>
> When I look at my /etc/krb5.conf, there's a kdc, master_kdc, and
> admin_server set for my domain.
> From what I had understood, I thought they should be ignored, and that the
> auto discovery should still happen.
> Is that so ?
>
> Thanks.
>
>
>
> On Tue, Jan 5, 2016 at 12:16 AM, Karl Forner 
> wrote:
>
>> 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] how to force switch to another kdc

[Karl Forner]

Thanks a lot, that works if I comment out the explicit reference to a
server name, and that I switch dns_lookup_kdc to true.

I think I understand why it was not working from the install:
I used the ipa-client-install with the option --server.
According to the man page, in the "Failover" section, I understand that
"DNS Autodiscovery" is enabled when no "fixed server was passed to the
installer", which makes sense a posteriori.


I think that closes my topic, thanks again for all the help I got !


On Tue, Jan 5, 2016 at 7:34 PM, Natxo Asenjo  wrote:

>
>
> On Tue, Jan 5, 2016 at 7:31 PM, Natxo Asenjo 
> wrote:
>
>> includedir /var/lib/sss/pubconf/krb5.include.d/
>> #File modified by ipa-client-install
>>
>> [libdefaults]
>>   default_realm = IPA.DOMAIN.TLD
>>   dns_lookup_realm = true
>>   dns_lookup_kdc = true
>>   rdns = false
>>   ticket_lifetime = 24h
>>   forwardable = yes
>>
>> [realms]
>>   IPA.DOMAIN.TLD = {
>> pkinit_anchors = FILE:/etc/ipa/ca.crt
>>   }
>>
>> [domain_realm]
>>   .ipa.domain.tld = IPA.DOMAIN.TLD
>>   ipa.domain.tld = IPA.DOMAIN.TLD
>>
>> ]$ cat /etc/krb5.conf
>>
>
> with this config I can reach any realm, by the way, provided it has srv
> records. It works for our AD forests as well.
>
> --
> Groeten,
> natxo
>
> --
> 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] how to force switch to another kdc

[Karl Forner]

On Tue, Jan 5, 2016 at 8:14 AM, Jakub Hrozek  wrote:

> On Tue, Jan 05, 2016 at 12:16:48AM +0100, Karl Forner wrote:
> > 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.
>
> As long as the authentication is done via sssd this should happen
> automatically,


well it does not seem to.
The way I test it is using kinit.
The only log that gets updated in /var/log/sssd is ldap_child.log.1
(what's strange is that there's a ldap_child.log which is empty).
Each time I try a kinit, I get a log line like:

(Tue Jan  5 18:10:55 2016) [[sssd[ldap_child[10069
[ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Cannot
contact any KDC for realm 'EXAMPLE.COM'

I tried to send USR1 then USR2 to the main sssd process, without any
improvement,


In a previous email, Simo Sorce explained me that:

Unfortunately it is, it is a bug in the way we update the krb5 libraries
> to point to a KDC.
>
> SSSD updates this information in a file under /var/lib/sss/pubconf and
> krb5 libraries read from it, however kinit cannot force sssd to
> re-evaluate if the file needs updating.
>
> If you do a local login instead of a kinit, you will see that SSSD will
> switch to the new server and subsequent kinit will start using it.
>
> This is tracked here:
> https://fedorahosted.org/sssd/ticket/941
>


Could this be related ?


but you can send USR1 followed by USR2 to sssd to force
> going offline and back online. It would be nice to look into the logs,
> though, to see why wouldn't sssd fail over itself.
>
> >
> > 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
>
> --
> 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] how to force switch to another kdc

[Natxo Asenjo]

On Tue, Jan 5, 2016 at 7:31 PM, Natxo Asenjo  wrote:

> includedir /var/lib/sss/pubconf/krb5.include.d/
> #File modified by ipa-client-install
>
> [libdefaults]
>   default_realm = IPA.DOMAIN.TLD
>   dns_lookup_realm = true
>   dns_lookup_kdc = true
>   rdns = false
>   ticket_lifetime = 24h
>   forwardable = yes
>
> [realms]
>   IPA.DOMAIN.TLD = {
> pkinit_anchors = FILE:/etc/ipa/ca.crt
>   }
>
> [domain_realm]
>   .ipa.domain.tld = IPA.DOMAIN.TLD
>   ipa.domain.tld = IPA.DOMAIN.TLD
>
> ]$ cat /etc/krb5.conf
>

with this config I can reach any realm, by the way, provided it has srv
records. It works for our AD forests as well.

--
Groeten,
natxo
-- 
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

[Rob Crittenden]

Lukas Slebodnik wrote:
> On (05/01/16 15:11), bahan w wrote:
>> Hello.
>>
>> I have some questions related to this point :
>> 1. On a RHEL6.6, may I install the package ipa-client 4.x and enroll to an
>> ipa server 4.x located on a RHEL7 ? May you remind me the version of sssd
>> embedded with ipa-client 4.x ?
> rhel6.6 has ipa-client-3.0.0-47.el6 and sssd-1.11.x
> rhel6.7 has ipa-client-3.0.0-47.el6 and sssd-1.12.x
> 
> and sssd-1.11+ works well with ipa-server 4.x

Strictly speaking, sssd isn't "embedded" with ipa-client. There is some
correlation based on distro release, as Lukas has listed, but that's
about it.

There is no IPA 4.x for RHEL 6.x.

>> 2. The ipa-server 4.x can only be installed on RHEL7+, true/false ?
>>
> true ( +fedora :-)
> 
> 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 4.2.0 / CentOS 7.2 / DNS Strangeness (Sub-domains)

[Petr Spacek]

On 6.1.2016 08:25, Petr Spacek wrote:
> On 6.1.2016 06:42, Devin wrote:
>> I am noticing a very strange issue with FreeIPA, I installed FreeIPA on a
>> fresh Virtual Machine called (idm.servers.lnx.ninja) and registered the
>> Kerberos domain as LNX.NINJA. Everything installs just fine without any
>> issues, and even when I log into FreeIPA and go to the DNS Manager i see
>> that it created a few zones as I would have expected (ie: Reverse zone for
>> 10.10.10.x, lnx.ninja zone, and servers.lnx.ninja zone. What I notice is
>> that if I try to do a DNS query for any record on the (lnx.ninja) zone it
>> fails even though there are records there, and if I query any records
>> inside the servers.lnx.ninja zone they work just fine. What I can't
>> understand is why are my DNS queries dying on the (lnx.ninja) zone.
>>
>> So for my test I created 2 (A) records one inside (lnx.ninja) and one
>> inside (servers.lnx.ninja). What would cause any DNS queries to lnx.ninja
>> to not succeed? I have duplicated this issue multiple times with several
>> other VM's using different domains and they have have same issue. Any
>> advise is appreciated!
>>
>> [root@idm ~]# dig @localhost blah.lnx.ninja
>>
>> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> @localhost blah.lnx.ninja
>> ; (2 servers found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50913
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;blah.lnx.ninja. IN A
>>
>> ;; Query time: 1 msec
>> ;; SERVER: ::1#53(::1)
>> ;; WHEN: Wed Jan 06 05:30:15 UTC 2016
>> ;; MSG SIZE  rcvd: 43
>>
>> [root@idm ~]# dig @localhost blah.servers.lnx.ninja
>>
>> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> @localhost
>> blah.servers.lnx.ninja
>> ; (2 servers found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64481
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;blah.servers.lnx.ninja. IN A
>>
>> ;; ANSWER SECTION:
>> blah.servers.lnx.ninja. 86400 IN A 10.10.10.1
>>
>> ;; AUTHORITY SECTION:
>> servers.lnx.ninja. 86400 IN NS idm.servers.lnx.ninja.
>>
>> ;; ADDITIONAL SECTION:
>> idm.servers.lnx.ninja. 1200 IN A 10.10.10.10
>>
>> ;; Query time: 0 msec
>> ;; SERVER: ::1#53(::1)
>> ;; WHEN: Wed Jan 06 05:30:32 UTC 2016
>> ;; MSG SIZE  rcvd: 101
> 
> 
> Hello,
> 
> this is strange, but I do not have sufficient information right now.
> 
> Please add following information:
> # list all configured DNS master zones
> $ ipa dnszone-find
> 
> # list all DNS forward zones
> $ ipa dnsforwardzone-find
> 
> # tell us exact RPM versions
> $ rpm -q bind bind-dyndb-ldap ipa-server

Ee, I forgot to ask for logs from named-pkcs11 service:
Please run
$ journalctl -u named-pkcs11
and look for messages related to the zone which has problems.

I'm sorry for the noise :-)

-- 
Petr^2 Spacek

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

[Freeipa-users] Importing from shadow: ERROR: Constraint violation: pre-hashed passwords are not valid

[Simpson Lachlan]

Hi,

New install of FreeIPA 4.2.0-15.el7.centos.3 on Centos 7.2.1511 (and I'm very 
new to FreeIPA)

Following the advice I got from here: 
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords

I dumped old shadow into a csv, then wrote a small bash script to import all 
the users:

#!/bin/bash
INPUT=s.csv
IFS=,

kinit admin

[ ! -f $INPUT ] && { echo "$INPUT file not found"; exit 99; }
while read lname pw
do

echo "Importing user $lname"
FIRST=${lname:0:1}
LAST=${lname:1}

ipa user-add $lname --first $FIRST --last $LAST --setattr 
userpassword={crypt}"$pw"


done < $INPUT

When I execute this, I get this error for every entry: "ipa: ERROR: Constraint 
violation: pre-hashed passwords are not valid"

What have I done wrong?

Cheers
L.

This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Fwd: NetworkError : invalid continuation byte with utf8 codec

[Fraser Tweedale]

On Mon, Jan 04, 2016 at 03:13:43PM +0100, Domineaux Philippe wrote:
> Hello,
> 
> Happy new year.
> 
> So the content of my /etc/locale.conf :
> 
> LANG="fr_FR.UTF-8"
> 
Happy new year to you too, and thanks for the info.

I reproduced the issue and there is a now a patch awaiting review.
Ticket: https://fedorahosted.org/freeipa/ticket/5578

Cheers,
Fraser

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

-- 
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.2.0 / CentOS 7.2 / DNS Strangeness (Sub-domains)

[Petr Spacek]

On 6.1.2016 06:42, Devin wrote:
> I am noticing a very strange issue with FreeIPA, I installed FreeIPA on a
> fresh Virtual Machine called (idm.servers.lnx.ninja) and registered the
> Kerberos domain as LNX.NINJA. Everything installs just fine without any
> issues, and even when I log into FreeIPA and go to the DNS Manager i see
> that it created a few zones as I would have expected (ie: Reverse zone for
> 10.10.10.x, lnx.ninja zone, and servers.lnx.ninja zone. What I notice is
> that if I try to do a DNS query for any record on the (lnx.ninja) zone it
> fails even though there are records there, and if I query any records
> inside the servers.lnx.ninja zone they work just fine. What I can't
> understand is why are my DNS queries dying on the (lnx.ninja) zone.
> 
> So for my test I created 2 (A) records one inside (lnx.ninja) and one
> inside (servers.lnx.ninja). What would cause any DNS queries to lnx.ninja
> to not succeed? I have duplicated this issue multiple times with several
> other VM's using different domains and they have have same issue. Any
> advise is appreciated!
> 
> [root@idm ~]# dig @localhost blah.lnx.ninja
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> @localhost blah.lnx.ninja
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50913
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;blah.lnx.ninja. IN A
> 
> ;; Query time: 1 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Wed Jan 06 05:30:15 UTC 2016
> ;; MSG SIZE  rcvd: 43
> 
> [root@idm ~]# dig @localhost blah.servers.lnx.ninja
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> @localhost
> blah.servers.lnx.ninja
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64481
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;blah.servers.lnx.ninja. IN A
> 
> ;; ANSWER SECTION:
> blah.servers.lnx.ninja. 86400 IN A 10.10.10.1
> 
> ;; AUTHORITY SECTION:
> servers.lnx.ninja. 86400 IN NS idm.servers.lnx.ninja.
> 
> ;; ADDITIONAL SECTION:
> idm.servers.lnx.ninja. 1200 IN A 10.10.10.10
> 
> ;; Query time: 0 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Wed Jan 06 05:30:32 UTC 2016
> ;; MSG SIZE  rcvd: 101


Hello,

this is strange, but I do not have sufficient information right now.

Please add following information:
# list all configured DNS master zones
$ ipa dnszone-find

# list all DNS forward zones
$ ipa dnsforwardzone-find

# tell us exact RPM versions
$ rpm -q bind bind-dyndb-ldap ipa-server

Thank you.

-- 
Petr^2 Spacek

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

[Freeipa-users] FreeIPA 4.2.0 / CentOS 7.2 / DNS Strangeness (Sub-domains)

[Devin]

I am noticing a very strange issue with FreeIPA, I installed FreeIPA on a
fresh Virtual Machine called (idm.servers.lnx.ninja) and registered the
Kerberos domain as LNX.NINJA. Everything installs just fine without any
issues, and even when I log into FreeIPA and go to the DNS Manager i see
that it created a few zones as I would have expected (ie: Reverse zone for
10.10.10.x, lnx.ninja zone, and servers.lnx.ninja zone. What I notice is
that if I try to do a DNS query for any record on the (lnx.ninja) zone it
fails even though there are records there, and if I query any records
inside the servers.lnx.ninja zone they work just fine. What I can't
understand is why are my DNS queries dying on the (lnx.ninja) zone.

So for my test I created 2 (A) records one inside (lnx.ninja) and one
inside (servers.lnx.ninja). What would cause any DNS queries to lnx.ninja
to not succeed? I have duplicated this issue multiple times with several
other VM's using different domains and they have have same issue. Any
advise is appreciated!

[root@idm ~]# dig @localhost blah.lnx.ninja

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> @localhost blah.lnx.ninja
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50913
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;blah.lnx.ninja. IN A

;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Jan 06 05:30:15 UTC 2016
;; MSG SIZE  rcvd: 43

[root@idm ~]# dig @localhost blah.servers.lnx.ninja

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> @localhost
blah.servers.lnx.ninja
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64481
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;blah.servers.lnx.ninja. IN A

;; ANSWER SECTION:
blah.servers.lnx.ninja. 86400 IN A 10.10.10.1

;; AUTHORITY SECTION:
servers.lnx.ninja. 86400 IN NS idm.servers.lnx.ninja.

;; ADDITIONAL SECTION:
idm.servers.lnx.ninja. 1200 IN A 10.10.10.10

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Jan 06 05:30:32 UTC 2016
;; MSG SIZE  rcvd: 101

Thanks Much.

Devin
-- 
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] how to force switch to another kdc

[Natxo Asenjo]

On Tue, Jan 5, 2016 at 7:22 PM, Karl Forner  wrote:

> update:
>
> modifying the /etc/krb5.conf, and replacing the name of my freeipa master
> by the replica fixes the problem.
> So that proves that the kdc is not picked up by discovery.
>
> The problem is that my ubuntu box was enrolled using the
> ipa-client-install script, and so should be properly configured.
>
> Did I miss any critical option ?
> What should the /etc/krb5.conf be like ?
>

Could you post your krb5.conf ?

This is a working example in a centos 6 host:

al-only additions here, put content in /etc/motd-local ##
]$ cat /etc/krb5.conf
includedir /var/lib/sss/pubconf/krb5.include.d/
#File modified by ipa-client-install

[libdefaults]
  default_realm = IPA.DOMAIN.TLD
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes

[realms]
  IPA.DOMAIN.TLD = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
  }

[domain_realm]
  .ipa.domain.tld = IPA.DOMAIN.TLD
  ipa.domain.tld = IPA.DOMAIN.TLD

-- 
regards,
natxo
-- 
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

[Roderick Johnstone]

On 05/01/2016 17:17, Rob Crittenden wrote:

Martin Kosek wrote:

On 01/05/2016 04:24 PM, Rob Crittenden wrote:

Martin Kosek wrote:

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.



I didn't but I can reproduce it.

It is probably due to this deny ACI:

aci: (targetfilter = "(objectClass=mepManagedEntry)")(targetattr =
"*")(version 3.0; acl "Managed netgroups cannot be modified"; deny
(write) userdn = "ldap:///all;;)


Ah, good catch. I was suspecting something like that, I just did not know we
went that far to create deny ACI.


Not very nice behavior (and deny ACIs are icky).

I guess the netgroup mod commands should look to see if it is a real
netgroup before trying to do a write and otherwise raise a more
reasonable error.


Potentially yes, although I do not see that as the most important part. I
rather do not know how to solve Roderick's issue and add external hosts as part
of the shadow netgroups.

Currently, the only workaround is to create plain host/ghost entries for these
non-ipa clients and use them in host groups.



That or use real netgroups created via netgroup-add instead of
hostgroups. That is the only way to have control over the advertised NIS
domain in the triple anyway.

rob



Martin/Rob

Thanks for all your analysis on this query.

I had come to the conclusion that using the real netgroups was probably 
the way to go on this in my particular circumstances. I'm happy now that 
I'm not missing something obvious about the managed netgroups which 
would make them a better choice.


Thanks again.

Roderick

--
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-users Digest, Vol 90, Issue 9

[Rob Crittenden]

BlueBolt wrote:
> Wow, that's fairly horrifying stuff, Rob.  All of my NFS servers (and
> current ldap-auth'd clients, which are not migrated to ipa-client) are
> constrained to nfs3.  I have no plans to v4 any of my nfs infrastructure
> apart from one server eventually which will serve mostly Macs for acl
> richness.  At any rate:
> 
> "To use GSS-Proxy with the NFS server you need a recent enough kernel.
> Anything more recent than 3.10 should work just fine."
> 
> Servers are CentOS6 and Nexenta where they'll remain for the foreseeable
> future.
> 
> Surely this is anticipated somewhere in the ipa/sssd universe allowing
> autofs to act in some autonomous way as it does currently with ldap backend?

I think you're confusing things. This doesn't remove any existing
behavior. You can still use ldap auth against autofs if you want, and
that is the default in ipa-client-automount using the host credentials.

But that isn't what you originally asked about. You asked about the
mounts themselves requiring Kerberos security. If you want want Kerberos
in the NFS mounts there is more pain in EL 6 than in EL 7. The typical
workaround is to use a keytab.

We can only move the earth so much at a time.

rob

> 
> thank you,
> 
> - cal sawyer
> 
> Date: Mon, 4 Jan 2016 14:07:40 -0500
>> From: Rob Crittenden >
>> To: Cal Sawyer >,
>> freeipa-users@redhat.com 
>> Subject: Re: [Freeipa-users] IPA, autofs, kerberos
>> Message-ID: <568ac2fc.6080...@redhat.com
>> >
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> 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] Freeipa-users Digest, Vol 90, Issue 9

[BlueBolt]

Wow, that's fairly horrifying stuff, Rob.  All of my NFS servers (and current 
ldap-auth'd clients, which are not migrated to ipa-client) are constrained to 
nfs3.  I have no plans to v4 any of my nfs infrastructure apart from one server 
eventually which will serve mostly Macs for acl richness.  At any rate:
"To use GSS-Proxy with the NFS server you need a recent enough kernel. Anything 
more recent than 3.10 should work just fine."

Servers are CentOS6 and Nexenta where they'll remain for the foreseeable future.

Surely this is anticipated somewhere in the ipa/sssd universe allowing autofs 
to act in some autonomous way as it does currently with ldap backend?

thank you,

- cal sawyer

> Date: Mon, 4 Jan 2016 14:07:40 -0500
> From: Rob Crittenden 
> To: Cal Sawyer , freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] IPA, autofs, kerberos
> Message-ID: <568ac2fc.6080...@redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> 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