Re: [Freeipa-users] Setting "preserve" as default action when deleting in webUI

[Sebastien Julliot]

Hello guys,


Thank you for your answers. First, I was able to modify the minified js
to change the default. Ugly solution, but it works for now.

I am trying to write a plugin but it seems that I missed something here
since, despite being executed, the default is not changed ..

Here is my code, freely inspired of what I think I understood of your
'association_search_fix.js' example:

define([

'freeipa/ipa',

'freeipa/user',

],

function(IPA, user) {

exp = {};

 

exp.orig_create_active_user_del_dialog = IPA.user.create_active_user_del_dialog;

IPA.user.create_active_user_del_dialog = function(dialog) {

dialog.deleter_dialog_create_content();

dialog.option_layout = IPA.fluid_layout({

label_cls: 'col-sm-3',

widget_cls: 'col-sm-9'

});

dialog.option_radio = IPA.radio_widget({

name: 'preserve',

label: '@i18n:objects.user.delete_mode',

options: [

{ label: '@i18n:objects.user.mode_delete', value: 'false' },

{ label: '@i18n:objects.user.mode_preserve', value: 'true' }

],

default_value: 'true'

});

var html = dialog.option_layout.create([dialog.option_radio]);

dialog.container.append(html);

dialog.option_radio.set_value(['']);

return dialog;

};

//exp.orig_create_active_user_del_dialog = 
IPA.user.create_active_user_del_dialog;

console.log('PRESERVE.JS WAS EXECUTED');

return exp;

});

I checked that disabling the comment or not does not change anything.


Can you see what I missed here ?


Thanks a lot,

Sebastien Julliot.



-- 
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] Why does a SAN field on a CSR require a host to be in IPA?

[Michael Ströder]

Fil Di Noto wrote:
> In my imagination, I see IPA for whatever reason comes accross a cert
> it signed in the past and decides it needs to compare the SAN to the
> directory. Then it sees the SAN doesn't have an associated principal
> in the directory. Who does IPA trust? (the directory obviously). IPA
> says, "is this SAN in the directory? No. Did I sign the cert? Yes.
> Should I trust the cert? Yes because I signed it."

Speaking purely from the PKI perspective without detailed knowledge about 
FreeIPA:

If the IPA directory is the only assured source of truth then the CA must revoke
the cert because its knowledge about the assertion made in the cert (this public
key belongs to this entity) cannot be verified anymore.

Note that the assertion made in a cert has to be valid for the *complete*
validity period of the cert, not only at the time of cert issuance.

=> If in doubt then revoke.

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 domains and sub-domains

[Alexander Bokovoy]

On to, 27 loka 2016, Brian Candler wrote:

On 27/10/2016 10:07, Brian Candler wrote:
To the OP: in that case, I'd still recommend that you choose a 
distinct kerberos realm like IPA.YOURCOMPANY.COM, with associated 
primary domain "ipa.yourcompany.com", and let FreeIPA manage that 
domain so that it sets up all the right SRV records for 
auto-discovery.  But you don't need to put any hosts inside that DNS 
domain at all.


Aside: I have just been trying this out.

What's slightly confusing is that the ipa server-install process 
requires you to set a "domain name" as well as a realm, and it's not 
clear to me which "domain" to put here. Is this the domain which 
corresponds to the realm, or the domain which the clients normally 
reside in, or something else?


For example, suppose I have realm IPA.MYCOMPANY.COM but my servers are 
xxx.int.mycompany.com.  Should I set the FreeIPA "domain" to 
ipa.mycompany.com or int.mycompany.com, or mycompany.com ?

It really depends on your taste, nothing else. There are some
technical details, though, that you should look at:

- Kerberos implementations have to deal with both realm to DNS and DNS
  to realm conversions. When there is no static configuration of KDCs
  per realm, MIT Kerberos would take the name of the realm and treat it
  as a DNS domain name to perform SRV record query
  (_kerberos._udp.REALM and _kerberos._tcp.REALM).

- for DNS hostname to realm conversion, if realm is unknown, MIT
  Kerberos might look up TXT record _kerberos.$domain.

These two details mean the following:

- DNS domain corresponding to your REALM should be under your control.
  Note that it effectively means if you are using single word REALM,
  you are asking for trouble with dynamic KDC resolution (do you own
  one-word top level domain .REALM? With DNSSEC?)

- all other domains where the same REALM is in use should have TXT
  record pointing to your REALM.

- As long as you can control how clients resolve DNS hostnames to REALM
  and discover configuration of the REALM, you should be fine.

This is why we recommend to have IPA primary DNS domain the same as REALM.
You can have both IPA masters and IPA clients in other DNS domains too
but the DNS domain named as your REALM has to be under your control.

Final detail is related to the forest trust to Active Directory.
Microsoft implementation of Active Directory protocol stack assumes your
DNS domain is equal to your realm and that _kerberos.udp or
_kerberos._tcp and _ldap._tcp SRV records for this domain point to the
proper Active Directory DCs authoritative for the forest of REALM.

This is why we recommend to have IPA primary DNS domain the same as REALM.
You can have both IPA masters and IPA clients in other DNS domains too
but the DNS domain named as your REALM has to be under your control.
This will make your life going forward much simpler.

After some experimentation, it seems that the LDAP baseDN is always 
taken from the realm (dc=ipa,dc=mycompany,dc=com). But the DNS domain 
is used for:


- nisDomain and associatedDomain
- ipaDefaultEmailDomain
- crucially, the SRV records are published under the DNS domain

So it looks like really you should put "ipa.mycompany.com" as the DNS 
domain, even if the IPA servers are in a different domain.

FreeIPA enforces realm to primary DNS domain through these elements,
right, out of practical needs outlined above.

--
/ 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] dns_tkey_negotiategss: failure GSSAPI error [...] Message stream modified.

[Tyrell Jentink]

Thank you Petr!  I found the problem, but quite by accident...  There may
be a Best Practice at hand that I wasn't aware of...

I still have the Windows AD server sitting on the side, serving as DHCP
server and waiting patiently for my Cross Realm Trust;  That server will
forward DNS requests to the IPA server, and return a non-authoritative
answer.  Occasionally, that server will seemingly loose track of the IPA
server, and stop returning results...  And that happened while I was trying
to follow through with your request for info...  So as a quick work around,
I simply dropped the AD server from my resolv.conf...

And then performed your requests, without errors.  I ran the DNS Update
from the ipa-server-install script, and that worked without errors.  I
added the AD server back into resolv.conf, and everything failed again. I
put the AD server as the SECOND name server in resolv.conf, and the errors
went away. So I've clearly identified the problem.

I uninstalled the client, and reinstalled the client, and everything went
cleanly.

To prevent this problem in the future...  I will be changing the DHCP
options to list the IPA DNS first for the Linux clients, and the AD DNS
first for Windows clients; I still want the AD DNS server in the list, as a
fallback. Is this plan the best practice here?

On Wed, Oct 26, 2016 at 11:36 PM, Petr Spacek  wrote:

> On 27.10.2016 04:43, Tyrell Jentink wrote:
> >> 2016-10-26T23:30:40Z DEBUG Writing nsupdate commands to
> >> > /etc/ipa/.dns_update.txt:
> >> > 2016-10-26T23:30:40Z DEBUG debug
> >> >
> >> > update delete trainmaster.ipa.rxrhouse.net. IN A
> >> > show
> >> > send
> >> >
> >> > update delete trainmaster.ipa.rxrhouse.net. IN 
> >> > show
> >> > send
> >> >
> >> > update add trainmaster.ipa.rxrhouse.net. 1200 IN A 10.42.0.100
> >> > show
> >> > send
> >> >
> >> > 2016-10-26T23:30:40Z DEBUG Starting external process
> >> > 2016-10-26T23:30:40Z DEBUG args=/usr/bin/nsupdate -g
> >> > /etc/ipa/.dns_update.txt
> >> > 2016-10-26T23:30:40Z DEBUG Process finished, return code=1
> >> > 2016-10-26T23:30:40Z DEBUG stdout=Outgoing update query:
> >> > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
> >> > ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
> >> > ;; UPDATE SECTION:
> >> > trainmaster.ipa.rxrhouse.net. 0 ANY A
> >> >
> >> > Outgoing update query:
> >> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  39562
> >> > ;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >> > ;; QUESTION SECTION:
> >> > ;3107127915.sig-ipa-pdc.ipa.rxrhouse.net. ANY TKEY
> >> >
> >> > ;; ADDITIONAL SECTION:
> >> > 3107127915.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig.
> 1477524640
> [...]
> >> >
> >> > 2016-10-26T23:30:40Z DEBUG stderr=Reply from SOA query:
> >> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  38738
> >> > ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1,
> ADDITIONAL: 0
> >> > ;; QUESTION SECTION:
> >> > ;trainmaster.ipa.rxrhouse.net.  IN  SOA
> >> >
> >> > ;; AUTHORITY SECTION:
> >> > ipa.rxrhouse.net.   0   IN  SOA
> ipa-pdc.ipa.rxrhouse.net.
> >> > hostmaster.ipa.rxrhouse.net. 1477524446 3600 900 1209600 3600
> >> >
> >> > Found zone name: ipa.rxrhouse.net
> >> > The master is: ipa-pdc.ipa.rxrhouse.net
> >> > start_gssrequest
> >> > Found realm from ticket: IPA.RXRHOUSE.NET
> >> > send_gssrequest
> >> > recvmsg reply from GSS-TSIG query
> >> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  39562
> >> > ;; flags: qr; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> >> > ;; QUESTION SECTION:
> >> > ;3107127915.sig-ipa-pdc.ipa.rxrhouse.net. ANY TKEY
> >> >
> >> > ;; ANSWER SECTION:
> >> > 3107127915.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig.
> 1466301805
> >> > 1466388205 3 NOERROR 101
> >> > YGMGCSqGSIb3EgECAgMAflQwUqADAgEFoQMCAR6kERgPMjAxNjA2MTkw
> >> > MjAzMjVapQUCAwHGkaYDAgEpqREbD0FELlJYUkhPVVNFLk5FVKoUMBKg
> >> > AwIBAaELMAkbB2FkLXBkYyQ=
> >> > 0
> >> >
> >> > dns_tkey_negotiategss: failure GSSAPI error: Major = Unspecified GSS
> >> > failure.  Minor code may provide more information, Minor = Message
> stream
> >> > modified.
> >> >
> >> > 2016-10-26T23:30:40Z DEBUG nsupdate failed: Command
> '/usr/bin/nsupdate -g
> >> > /etc/ipa/.dns_update.txt' returned non-zero exit status 1
> >> > 2016-10-26T23:30:40Z ERROR Failed to update DNS records.
> >> > 2016-10-26T23:30:40Z DEBUG DNS resolver: Query:
> >> > trainmaster.ipa.rxrhouse.net IN A
> >> > 2016-10-26T23:30:40Z DEBUG DNS resolver: No record.
> >> > 2016-10-26T23:30:40Z DEBUG DNS resolver: Query:
> >> > trainmaster.ipa.rxrhouse.net IN 
> >> > 2016-10-26T23:30:40Z DEBUG DNS resolver: No record.
> >> > 2016-10-26T23:30:40Z DEBUG DNS resolver: Query:
> 100.0.42.10.in-addr.arpa.
> >> > IN PTR
> >> > 2016-10-26T23:30:40Z DEBUG DNS resolver: No record.
> >> > 2016-10-26T23:30:40Z WARNING Missing A/ record(s) for host
> >> > trainmaster.ipa.rxrhouse.net: 10.42.0.100.
> >> > 

Re: [Freeipa-users] Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired)

[bahan w]

Help ?

Best regards.

Bahan

On Tue, Oct 25, 2016 at 1:00 PM, bahan w  wrote:

> Re.
>
> There is no time difference between client and server.
>
> I checked the httpd error log and saw no errors.
> Same with the dirsrv error logs.
>
> Any other idea ?
>
> By looking at the  log, I'm wondering if this is a question of session ?
>
> See there :
> ###
> ipa: DEBUG: args=keyctl pipe 44063864
> ipa: DEBUG: stdout=ipa_session=26a7252e4853374fc7439eae5926c584;
> Domain=; Path=/ipa; Expires=Tue, 25 Oct 2016 08:15:09 GMT;
> Secure; HttpOnly
> ipa: DEBUG: stderr=
> ipa: DEBUG: found session_cookie in persistent storage for principal
> '@', cookie: 'ipa_session=26a7252e4853374fc7439eae5926c584;
> Domain=; Path=/ipa; Expires=Tue, 25 Oct 2016 08:15:09 GMT;
> Secure; HttpOnly'
> ipa: DEBUG: setting session_cookie into context
> 'ipa_session=26a7252e4853374fc7439eae5926c584;'
> ###
>
> At that time, it was not yet expired but there was only a few minuts
> before expiration (something like 10 minuts).
> What is this persistent storage which is mentioned in the logs ?
>
> Best regards.
>
> Bahan
>
>
>
> On Tue, Oct 25, 2016 at 12:18 PM, Martin Babinsky 
> wrote:
>
>> On 10/25/2016 10:27 AM, bahan w wrote:
>>
>>> Hello everyone !
>>>
>>> I have an ipa server and an ipa client both in 3.0.0-47.
>>>
>>> In order to connect via SSH to the host of the ipa-client, I use root.
>>> When I'm connected to the ipa-client via ssh being root, I do a kinit of
>>> a user with a keytab :
>>> ###
>>> kinit -kt /etc/security/keytabs/.headless.keytab 
>>> ###
>>>
>>> And sometimes, once I have the TGT, when I do just an ipa user-show, I
>>> got the following error :
>>> ###
>>> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI
>>> Error: Unspecified GSS failure.  Minor code may provide more information
>>> (Ticket expired)
>>> ###
>>>
>>> When I check the ticket, it is not expired :
>>> ###
>>> # klist
>>> Ticket cache: FILE:/tmp/krb5cc_root_
>>> Default principal: @
>>>
>>> Valid starting ExpiresService principal
>>> 10/25/16 10:00:44  10/26/16 10:00:44  krbtgt/@
>>> ###
>>>
>>> Do you know from where it can come and how I can solve this error please
>>> ?
>>>
>>> Here is more information with the debug option :
>>> ###
>>> ipa -d user-show 
>>> ###
>>>
>>> Result :
>>> ###
>>> ipa: DEBUG: importing all plugin modules in
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins'...
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/aci.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/automember.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/automount.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/batch.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/cert.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/config.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/group.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacrule.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvc.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/hbacsvcgroup.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/hbactest.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/host.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/hostgroup.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/idrange.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/kerberos.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/krbtpolicy.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/migration.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/misc.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/netgroup.py'
>>> ipa: DEBUG: importing plugin module
>>> '/usr/lib/python2.6/site-packages/ipalib/plugins/passwd.py'
>>> ipa: 

Re: [Freeipa-users] cn=deleted users,cn=accounts

[Petr Vobornik]

On 10/27/2016 02:45 PM, Michael Ströder wrote:
> Michael Ströder wrote:
>> I wonder which action in the FreeIPA Web UI (4.2.0) moves an active user to
>> this container:
>>
>> cn=deleted users,cn=accounts,cn=provisioning,dc=example,dc=com
>>
>> Selecting [Delete] as action really deletes the LDAP entry.
> 
> Ah, found it myself:
> It makes a difference choosing action [Delete] when displaying a single user
> entry or from the user overview table. The latter asks whether to preserve the
> entry or not.
> 
> Is this UI inconsistency fixed in a later release?

Yes, it has been fixed in 4.4 release.

> 
> Ciao, Michael.
> 


-- 
Petr Vobornik

-- 
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 automount bug?

[William Muriithi]

>>
>> [root@hydrogen ~]# ipa automountmap-add-indirect default
>> auto.projects-prs1013 –-mount=/projects/prs1013
>> --parentmap=auto.projects
>
> Is this a direct copy-paste from the terminal? If so and your e-mail client
> did not do any reformatting then the first character in the
> "–-mount=/projects/prs1013" is not a dash, which results in it being
> recognized as a third argument, thus the warning about at most 2 arguments.
>

Thanks for that observation.  It was indeed the case and it worked
when I fixed that typo.  Thanks a bunch

William


>>
>> ipa: ERROR: command 'automountmap_add_indirect' takes at most 2 arguments
>>
>>   I had got the idea that this is possible from the documentation below:
>>
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/configuring-maps.html
ported keys:
William

-- 
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] cn=deleted users,cn=accounts

[Michael Ströder]

Michael Ströder wrote:
> I wonder which action in the FreeIPA Web UI (4.2.0) moves an active user to
> this container:
> 
> cn=deleted users,cn=accounts,cn=provisioning,dc=example,dc=com
> 
> Selecting [Delete] as action really deletes the LDAP entry.

Ah, found it myself:
It makes a difference choosing action [Delete] when displaying a single user
entry or from the user overview table. The latter asks whether to preserve the
entry or not.

Is this UI inconsistency fixed in a later release?

Ciao, Michael.




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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] cn=deleted users,cn=accounts

[Michael Ströder]

HI!

I wonder which action in the FreeIPA Web UI (4.2.0) moves an active user to this
container:

cn=deleted users,cn=accounts,cn=provisioning,dc=example,dc=com

Selecting [Delete] as action really deletes the LDAP entry.

Likely I missed something.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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-replica-prepare failing

[Rob Crittenden]

Joshua Ruybal wrote:

While trying to run IPA replica prepare with debug, we see an
unexplained failure.

Debug seems to show the process running smoothly, then I see:
"Certificate issuance failed".

Looking at previous mail-archives, I see that someone has run into this
before, however all permissions on caIPAserviceCert.cfg are correct (the
solution for him).

Is there any method to get more details on the failure from
ipa-replica-prepare?


I'd check the dogtag logs. This error is thrown when no certificate is 
issued by the CA.


There is no way other than instrumenting the code to get more details 
about the error from ipa-replica-prepare.


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] ipa automount bug?

[Rob Crittenden]

Standa Laznicka wrote:

Hello,

I am no automount expert so I will leave answering those questions to
those but see my comment inline.

On 10/27/2016 06:16 AM, William Muriithi wrote:

Evening,

I am trying to import some autos map from a file to FreeIPA LDAP and
have noticed two problems that can be considered a bug in my humble
opinion.  This is on:

ipa-server-4.2.0-15.0.1.el7

1.  This either is a documentation bug that suggest one can specify a
parent map while thats actually not the case or ipa I am running has a
bug and can't handle parent map. Below is what I get when I try to
specify parent map:

[root@hydrogen ~]# ipa automountmap-add-indirect default
auto.projects-prs1013 –-mount=/projects/prs1013
--parentmap=auto.projects

Is this a direct copy-paste from the terminal? If so and your e-mail
client did not do any reformatting then the first character in the
"–-mount=/projects/prs1013" is not a dash, which results in it being
recognized as a third argument, thus the warning about at most 2 arguments.


ipa: ERROR: command 'automountmap_add_indirect' takes at most 2 arguments

  I had got the idea that this is possible from the documentation below:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/configuring-maps.html


According to the document, I should be able to specify an automap
parent.  However, it don’t look like that’s actually supported.



2. How would one import an existing maps to ipa auto.home map.  Import
seem to be only capable of importing to auto.master, which make its
utility doubtful

[root@hydrogen ~]# ipa automountlocation-import  default
/tmp/2016-10-26/auto.home

Imported maps:
Imported keys:

Added adam to auto.master
..

I think we should have a flag that allow importation of key to other
other maps other than auto.master


You're right, auto.master is hardcoded. Please open an RFE for this if 
you need to be able to specify the mount.


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] ipa-replica-install fails because dirsrv failed to start

[Martin Babinsky]

On 10/27/2016 10:48 AM, Jochen Demmer wrote:



Am 27.10.2016 um 10:21 schrieb Martin Basti:




On 27.10.2016 10:02, Jochen Demmer wrote:



Am 26.10.2016 um 17:31 schrieb Martin Basti:




On 26.10.2016 17:25, Jochen Demmer wrote:



Am 26.10.2016 um 16:48 schrieb Martin Basti:




On 26.10.2016 16:42, Jochen Demmer wrote:



Am 26.10.2016 um 16:27 schrieb Martin Basti:




On 26.10.2016 16:10, Jochen Demmer wrote:

Hi,

my answers also inline.

Am 26.10.2016 um 15:38 schrieb Martin Basti:


Hi, comments inline


On 26.10.2016 14:28, Jochen Demmer wrote:

Hi,

I've been running and using a single FreeIPA server
successfully, i.e.:
Fedora 24
freeipa-server-4.3.2-2.fc24.x86_64
This server is only available via IPv6, because I can't get
public lPv4 addresses no more.

Now I want to setup a FreeIPA replica at another site also
running IPv6, Fedora 24 and freeipa-server-4.3.2-2.fc24.x86_64
First I run "ipa-client-install" which succeeds without an error.
When I invoke "ipa-replica-install" I get this error:
ipa : ERRORCould not resolve hostname
*hostname.mydoma.in* using DNS. Clients may not function
properly. Please check your DNS setup. (Note that this check
queries IPA DNS directly and ignores /etc/hosts.)
LOG:
2016-10-26T12:14:39Z DEBUG Search DNS server
*hostname.mydoma.in* (['2a01:f11:1:1::1', '2a01:f11:1:1::1',
'2a01:f11:1:1::1']) for *hostname.mydoma.in*


Can you check with dig or host command if the hostname is
really resolvable on that machine? do you have proper resolver
in /etc/resolv.conf?

There is a resolver given in /etc/resolv.conf. When I do "host
<>" I get the right IPv6 back.

That is weird because IPA is doing basically the same.





*hostname.mydoma.in* is actually the DNS entry for the old
FreeIPA server, which actually resolves, but only to an IPv6
address of course.
I can continue the installation though by entering "yes".

I then get asked:
Enter the IP address to use, or press Enter to finish.
Please provide the IP address to be used for this host name:

When I enter the IPv6 address of the new replica host it
doesn't accept but infinitely asks this question instead.


Have you pressed enter twice? It should end prompt and
continue with installation

Enter without an IP -> No usable IP address provided nor resolved.
Enter with an IP -> Error: Invalid IP Address 2a02:1:2:3::4
cannot use IP network address 2a02:1:2:3::4


How do you have configured IP address on your interface? Does it
have prefix /128?

Yes, that's right. It's an IP being assigned statefully by a
DHCPv6 server.
There is also another dynamic IP within the same prefix having
/64. I don't want to use this one of course, because its IID changes.


Could you set (temporarily) prefix for that address to /64 and
re-run installer? IPA 4.3 has check that prevents you to use /128
prefix

Well now I don't even get asked for the IP. The setup wizard
continues, but I now get this error:

  [27/43]: restarting directory server
ipa : CRITICAL Failed to restart the directory server
(Command '/bin/systemctl restart dirsrv@MY-REALM.service' returned
non-zero exit status 1). See the installation log for details.
  [28/43]: setting up initial replication
  [error] error: [Errno 111] Connection refused

LOG:
2016-10-26T15:14:46Z DEBUG Process finished, return code=1
2016-10-26T15:14:46Z DEBUG stdout=
2016-10-26T15:14:46Z DEBUG stderr=Job for dirsrv@MY-REALM.service
failed because the control process exited with error code. See
"systemctl status dirsrv@MY-REALM.service" and "journalctl -xe" for
details.
2016-10-26T15:14:46Z CRITICAL Failed to restart the directory
server (Command '/bin/systemctl restart dirsrv@MY-REALM.service'
returned non-zero exit status 1). See the installation log for details.
2016-10-26T15:14:46Z DEBUG   duration: 1 seconds
2016-10-26T15:14:46Z DEBUG   [28/43]: setting up initial replication
2016-10-26T15:14:56Z DEBUG Traceback (most recent call last):

When I try to restart manually with, "/bin/systemctl restart
dirsrv@MY-REALM.service"
 this is what systemd logs:
https://paste.fedoraproject.org/461439/raw/




Could you please check /var/log/dirsrv/slapd-*/errors  there might
be more details.

Did you reused an old IPA server for this installation?

Martin

This is what the logfile says:
https://paste.fedoraproject.org/461685/raw/

I tried to install this server as a replica a couple of times, but I
even reinstalled all of the software and I keep using
ipa-client-install --uninstall and
ipa-server-install --uninstall


It looks that DS database is somehow corrupted, is possible that there
might be some leftovers from previous installations

start: Failed to start databases, err=-1 BDB0092 Unknown error: -1

I'm not sure what that error means, maybe DS guys will know

Can you run server uninstall twice? It should remove all leftovers,
and then check /var/lib/dirsrv/ if there are any slapd-* directories,
if yes please remove them

Martin

I uninstalled freeipa-*, deleted /etc/dirsrv and 

Re: [Freeipa-users] ipa-replica-install fails because of IPv6?

[Martin Basti]

On 27.10.2016 10:33, Jochen Demmer wrote:



Am 27.10.2016 um 10:02 schrieb Jochen Demmer:



Am 26.10.2016 um 17:31 schrieb Martin Basti:




On 26.10.2016 17:25, Jochen Demmer wrote:



Am 26.10.2016 um 16:48 schrieb Martin Basti:




On 26.10.2016 16:42, Jochen Demmer wrote:



Am 26.10.2016 um 16:27 schrieb Martin Basti:




On 26.10.2016 16:10, Jochen Demmer wrote:

Hi,

my answers also inline.

Am 26.10.2016 um 15:38 schrieb Martin Basti:


Hi, comments inline


On 26.10.2016 14:28, Jochen Demmer wrote:

Hi,

I've been running and using a single FreeIPA server 
successfully, i.e.:

Fedora 24
freeipa-server-4.3.2-2.fc24.x86_64
This server is only available via IPv6, because I can't get 
public lPv4 addresses no more.


Now I want to setup a FreeIPA replica at another site also 
running IPv6, Fedora 24 and freeipa-server-4.3.2-2.fc24.x86_64

First I run "ipa-client-install" which succeeds without an error.
When I invoke "ipa-replica-install" I get this error:
ipa : ERRORCould not resolve hostname 
*hostname.mydoma.in* using DNS. Clients may not function 
properly. Please check your DNS setup. (Note that this check 
queries IPA DNS directly and ignores /etc/hosts.)

LOG:
2016-10-26T12:14:39Z DEBUG Search DNS server 
*hostname.mydoma.in* (['2a01:f11:1:1::1', '2a01:f11:1:1::1', 
'2a01:f11:1:1::1']) for *hostname.mydoma.in*


Can you check with dig or host command if the hostname is 
really resolvable on that machine? do you have proper resolver 
in /etc/resolv.conf?
There is a resolver given in /etc/resolv.conf. When I do "host 
<>" I get the right IPv6 back.

That is weird because IPA is doing basically the same.





*hostname.mydoma.in* is actually the DNS entry for the old 
FreeIPA server, which actually resolves, but only to an IPv6 
address of course.

I can continue the installation though by entering "yes".

I then get asked:
Enter the IP address to use, or press Enter to finish.
Please provide the IP address to be used for this host name:

When I enter the IPv6 address of the new replica host it 
doesn't accept but infinitely asks this question instead.


Have you pressed enter twice? It should end prompt and 
continue with installation

Enter without an IP -> No usable IP address provided nor resolved.
Enter with an IP -> Error: Invalid IP Address 2a02:1:2:3::4 
cannot use IP network address 2a02:1:2:3::4 


How do you have configured IP address on your interface? Does it 
have prefix /128?
Yes, that's right. It's an IP being assigned statefully by a 
DHCPv6 server.
There is also another dynamic IP within the same prefix having 
/64. I don't want to use this one of course, because its IID changes.


Could you set (temporarily) prefix for that address to /64 and 
re-run installer? IPA 4.3 has check that prevents you to use /128 
prefix
Well now I don't even get asked for the IP. The setup wizard 
continues, but I now get this error:


  [27/43]: restarting directory server
ipa : CRITICAL Failed to restart the directory server 
(Command '/bin/systemctl restart dirsrv@MY-REALM.service' returned 
non-zero exit status 1). See the installation log for details.

  [28/43]: setting up initial replication
  [error] error: [Errno 111] Connection refused

LOG:
2016-10-26T15:14:46Z DEBUG Process finished, return code=1
2016-10-26T15:14:46Z DEBUG stdout=
2016-10-26T15:14:46Z DEBUG stderr=Job for dirsrv@MY-REALM.service 
failed because the control process exited with error code. See 
"systemctl status dirsrv@MY-REALM.service" and "journalctl -xe" for 
details.
2016-10-26T15:14:46Z CRITICAL Failed to restart the directory 
server (Command '/bin/systemctl restart dirsrv@MY-REALM.service' 
returned non-zero exit status 1). See the installation log for details.

2016-10-26T15:14:46Z DEBUG   duration: 1 seconds
2016-10-26T15:14:46Z DEBUG   [28/43]: setting up initial replication
2016-10-26T15:14:56Z DEBUG Traceback (most recent call last):

When I try to restart manually with, "/bin/systemctl restart 
dirsrv@MY-REALM.service"

 this is what systemd logs:
https://paste.fedoraproject.org/461439/raw/




Could you please check /var/log/dirsrv/slapd-*/errors  there might 
be more details.


Did you reused an old IPA server for this installation?

Martin

This is what the logfile says:
https://paste.fedoraproject.org/461685/raw/

I tried to install this server as a replica a couple of times, but I 
even reinstalled all of the software and I keep using

ipa-client-install --uninstall and
ipa-server-install --uninstall

It looks like you encountered that problem yourself nearly a year ago:
https://fedorahosted.org/freeipa/ticket/5561


IPA hasn't been released with this bug, it was in development version only.














Honestly, I can't see what I might have done wrong.
Old FreeIPA has hostname is in sync forward and reverse record.
New FreeIPA host as well has hostname that symmetrically 
resolves, even though the hostname is using another second 
level domain.


Any hints?
Jochen Demmer

Re: [Freeipa-users] ipa automount bug?

[Standa Laznicka]

Hello,

I am no automount expert so I will leave answering those questions to 
those but see my comment inline.


On 10/27/2016 06:16 AM, William Muriithi wrote:

Evening,

I am trying to import some autos map from a file to FreeIPA LDAP and
have noticed two problems that can be considered a bug in my humble
opinion.  This is on:

ipa-server-4.2.0-15.0.1.el7

1.  This either is a documentation bug that suggest one can specify a
parent map while thats actually not the case or ipa I am running has a
bug and can't handle parent map. Below is what I get when I try to
specify parent map:

[root@hydrogen ~]# ipa automountmap-add-indirect default
auto.projects-prs1013 –-mount=/projects/prs1013
--parentmap=auto.projects
Is this a direct copy-paste from the terminal? If so and your e-mail 
client did not do any reformatting then the first character in the 
"–-mount=/projects/prs1013" is not a dash, which results in it being 
recognized as a third argument, thus the warning about at most 2 arguments.


ipa: ERROR: command 'automountmap_add_indirect' takes at most 2 arguments

  I had got the idea that this is possible from the documentation below:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/configuring-maps.html

According to the document, I should be able to specify an automap
parent.  However, it don’t look like that’s actually supported.



2. How would one import an existing maps to ipa auto.home map.  Import
seem to be only capable of importing to auto.master, which make its
utility doubtful

[root@hydrogen ~]# ipa automountlocation-import  default
/tmp/2016-10-26/auto.home

Imported maps:
Imported keys:

Added adam to auto.master
..

I think we should have a flag that allow importation of key to other
other maps other than auto.master

Regards,
William



--
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] rpm dependencies

[lejeczek]

On 27/10/16 09:28, Alexander Bokovoy wrote:
# rpm -q --requires freeipa-server|grep ^lib|xargs -n1 rpm 
-q --whatprovides|sort -u

glibc-2.23.1-10.fc24.x86_64
krb5-libs-1.14.4-4.fc24.x86_64
libcom_err-1.42.13-4.fc24.x86_64
libgcc-6.2.1-2.fc24.x86_64
libsss_nss_idmap-1.14.2-1.fc24.x86_64
libtalloc-2.1.6-1.fc24.x86_64
libtevent-0.9.28-1.fc24.x86_64
libunistring-0.9.4-3.fc24.x86_64
libuuid-2.28.2-1.fc24.x86_64
libverto-0.2.6-6.fc24.x86_64
nspr-4.13.1-1.fc24.x86_64
nss-3.27.0-1.1.fc24.x86_64
nss-util-3.27.0-1.0.fc24.x86_64
openldap-2.4.44-1.fc24.x86_64
openssl-libs-1.0.2j-1.fc24.x86_64
samba-client-libs-4.4.6-1.fc24.x86_64

You cannot remove samba-client-libs due to this.

We also do not support downgrading Samba. 


ough, this is not good this Siamese-twins type of existence.
AD easy integration is very nice thing to have but 
admins/users should also be able to equally easy disintegrate.
It to me goes way too weird - sssd won't exist (according to 
rpm deps logic) without sssd-ad and then IPA follows.


We should have IPA which does not depend on Samba.
I myself am in a sticky wicket situation right now - my BDC 
Samba 4.2.x on Centos 7 is not happy with userdb 
multi-master ldap backend, PDC which is Centos 6.8 with 
3.6.23-36.el6_8 has ruled that little domain fine for many 
years and win clients, etc are a OK. But Samba 4.2.x fails.
I believe it might be a bug - I have even submitted a 
report: https://bugzilla.redhat.com/show_bug.cgi?id=1388589 
- but I'm stuck!! I cannot try (at least not in orderly 
manner) any Samba 3 version which I believe would be quick & 
nice fix to my problem.

I'm stuck between these Siamese twins.
hmm...kupa.
L.

--
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 domains and sub-domains

[Brian Candler]

On 27/10/2016 09:30, Alexander Bokovoy wrote:

Yes, you can do that, there is no issue at all.


Thank you for confirming that.

To the OP: in that case, I'd still recommend that you choose a distinct 
kerberos realm like IPA.YOURCOMPANY.COM, with associated primary domain 
"ipa.yourcompany.com", and let FreeIPA manage that domain so that it 
sets up all the right SRV records for auto-discovery.  But you don't 
need to put any hosts inside that DNS domain at all.


This gives you the flexibility to set up future Kerberos realms like 
AD.YOURCOMPANY.COM if you deploy Active Directory or Samba4 later.


Regards,

Brian.

--
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-replica-install fails because dirsrv failed to start

[Ludwig Krispenz]

On 10/27/2016 10:48 AM, Jochen Demmer wrote:



Am 27.10.2016 um 10:21 schrieb Martin Basti:




On 27.10.2016 10:02, Jochen Demmer wrote:



Am 26.10.2016 um 17:31 schrieb Martin Basti:




On 26.10.2016 17:25, Jochen Demmer wrote:



Am 26.10.2016 um 16:48 schrieb Martin Basti:




On 26.10.2016 16:42, Jochen Demmer wrote:



Am 26.10.2016 um 16:27 schrieb Martin Basti:




On 26.10.2016 16:10, Jochen Demmer wrote:

Hi,

my answers also inline.

Am 26.10.2016 um 15:38 schrieb Martin Basti:


Hi, comments inline


On 26.10.2016 14:28, Jochen Demmer wrote:

Hi,

I've been running and using a single FreeIPA server 
successfully, i.e.:

Fedora 24
freeipa-server-4.3.2-2.fc24.x86_64
This server is only available via IPv6, because I can't get 
public lPv4 addresses no more.


Now I want to setup a FreeIPA replica at another site also 
running IPv6, Fedora 24 and freeipa-server-4.3.2-2.fc24.x86_64
First I run "ipa-client-install" which succeeds without an 
error.

When I invoke "ipa-replica-install" I get this error:
ipa : ERRORCould not resolve hostname 
*hostname.mydoma.in* using DNS. Clients may not function 
properly. Please check your DNS setup. (Note that this check 
queries IPA DNS directly and ignores /etc/hosts.)

LOG:
2016-10-26T12:14:39Z DEBUG Search DNS server 
*hostname.mydoma.in* (['2a01:f11:1:1::1', '2a01:f11:1:1::1', 
'2a01:f11:1:1::1']) for *hostname.mydoma.in*


Can you check with dig or host command if the hostname is 
really resolvable on that machine? do you have proper 
resolver in /etc/resolv.conf?
There is a resolver given in /etc/resolv.conf. When I do "host 
<>" I get the right IPv6 back.

That is weird because IPA is doing basically the same.





*hostname.mydoma.in* is actually the DNS entry for the old 
FreeIPA server, which actually resolves, but only to an IPv6 
address of course.

I can continue the installation though by entering "yes".

I then get asked:
Enter the IP address to use, or press Enter to finish.
Please provide the IP address to be used for this host name:

When I enter the IPv6 address of the new replica host it 
doesn't accept but infinitely asks this question instead.


Have you pressed enter twice? It should end prompt and 
continue with installation

Enter without an IP -> No usable IP address provided nor resolved.
Enter with an IP -> Error: Invalid IP Address 2a02:1:2:3::4 
cannot use IP network address 2a02:1:2:3::4 


How do you have configured IP address on your interface? Does 
it have prefix /128?
Yes, that's right. It's an IP being assigned statefully by a 
DHCPv6 server.
There is also another dynamic IP within the same prefix having 
/64. I don't want to use this one of course, because its IID 
changes.


Could you set (temporarily) prefix for that address to /64 and 
re-run installer? IPA 4.3 has check that prevents you to use /128 
prefix
Well now I don't even get asked for the IP. The setup wizard 
continues, but I now get this error:


  [27/43]: restarting directory server
ipa : CRITICAL Failed to restart the directory server 
(Command '/bin/systemctl restart dirsrv@MY-REALM.service' returned 
non-zero exit status 1). See the installation log for details.

  [28/43]: setting up initial replication
  [error] error: [Errno 111] Connection refused

LOG:
2016-10-26T15:14:46Z DEBUG Process finished, return code=1
2016-10-26T15:14:46Z DEBUG stdout=
2016-10-26T15:14:46Z DEBUG stderr=Job for dirsrv@MY-REALM.service 
failed because the control process exited with error code. See 
"systemctl status dirsrv@MY-REALM.service" and "journalctl -xe" 
for details.
2016-10-26T15:14:46Z CRITICAL Failed to restart the directory 
server (Command '/bin/systemctl restart dirsrv@MY-REALM.service' 
returned non-zero exit status 1). See the installation log for 
details.

2016-10-26T15:14:46Z DEBUG   duration: 1 seconds
2016-10-26T15:14:46Z DEBUG   [28/43]: setting up initial replication
2016-10-26T15:14:56Z DEBUG Traceback (most recent call last):

When I try to restart manually with, "/bin/systemctl restart 
dirsrv@MY-REALM.service"

 this is what systemd logs:
https://paste.fedoraproject.org/461439/raw/




Could you please check /var/log/dirsrv/slapd-*/errors  there might 
be more details.


Did you reused an old IPA server for this installation?

Martin

This is what the logfile says:
https://paste.fedoraproject.org/461685/raw/

I tried to install this server as a replica a couple of times, but I 
even reinstalled all of the software and I keep using

ipa-client-install --uninstall and
ipa-server-install --uninstall


It looks that DS database is somehow corrupted, is possible that 
there might be some leftovers from previous installations


start: Failed to start databases, err=-1 BDB0092 Unknown error: -1

I'm not sure what that error means, maybe DS guys will know

Can you run server uninstall twice? It should remove all leftovers, 
and then check /var/lib/dirsrv/ if there are any slapd-* directories, 
if yes please remove them


Martin
I 

Re: [Freeipa-users] ipa-replica-install fails because dirsrv failed to start

[Jochen Demmer]

Am 27.10.2016 um 10:21 schrieb Martin Basti:
>
>
>
> On 27.10.2016 10:02, Jochen Demmer wrote:
>>
>>
>> Am 26.10.2016 um 17:31 schrieb Martin Basti:
>>>
>>>
>>>
>>> On 26.10.2016 17:25, Jochen Demmer wrote:


 Am 26.10.2016 um 16:48 schrieb Martin Basti:
>
>
>
> On 26.10.2016 16:42, Jochen Demmer wrote:
>>
>>
>> Am 26.10.2016 um 16:27 schrieb Martin Basti:
>>>
>>>
>>>
>>> On 26.10.2016 16:10, Jochen Demmer wrote:
 Hi,

 my answers also inline.

 Am 26.10.2016 um 15:38 schrieb Martin Basti:
>
> Hi, comments inline
>
>
> On 26.10.2016 14:28, Jochen Demmer wrote:
>> Hi,
>>
>> I've been running and using a single FreeIPA server
>> successfully, i.e.:
>> Fedora 24
>> freeipa-server-4.3.2-2.fc24.x86_64
>> This server is only available via IPv6, because I can't get
>> public lPv4 addresses no more.
>>
>> Now I want to setup a FreeIPA replica at another site also
>> running IPv6, Fedora 24 and freeipa-server-4.3.2-2.fc24.x86_64
>> First I run "ipa-client-install" which succeeds without an error.
>> When I invoke "ipa-replica-install" I get this error:
>> ipa : ERRORCould not resolve hostname
>> *hostname.mydoma.in* using DNS. Clients may not function
>> properly. Please check your DNS setup. (Note that this check
>> queries IPA DNS directly and ignores /etc/hosts.)
>> LOG:
>> 2016-10-26T12:14:39Z DEBUG Search DNS server
>> *hostname.mydoma.in* (['2a01:f11:1:1::1', '2a01:f11:1:1::1',
>> '2a01:f11:1:1::1']) for *hostname.mydoma.in*
>
> Can you check with dig or host command if the hostname is
> really resolvable on that machine? do you have proper resolver
> in /etc/resolv.conf?
 There is a resolver given in /etc/resolv.conf. When I do "host
 <>" I get the right IPv6 back.
>>> That is weird because IPA is doing basically the same.
>>>
>
>>
>> *hostname.mydoma.in* is actually the DNS entry for the old
>> FreeIPA server, which actually resolves, but only to an IPv6
>> address of course.
>> I can continue the installation though by entering "yes".
>>
>> I then get asked:
>> Enter the IP address to use, or press Enter to finish.
>> Please provide the IP address to be used for this host name:
>>
>> When I enter the IPv6 address of the new replica host it
>> doesn't accept but infinitely asks this question instead.
>
> Have you pressed enter twice? It should end prompt and
> continue with installation
 Enter without an IP -> No usable IP address provided nor resolved.
 Enter with an IP -> Error: Invalid IP Address 2a02:1:2:3::4
 cannot use IP network address 2a02:1:2:3::4 
>>>
>>> How do you have configured IP address on your interface? Does it
>>> have prefix /128?
>> Yes, that's right. It's an IP being assigned statefully by a
>> DHCPv6 server.
>> There is also another dynamic IP within the same prefix having
>> /64. I don't want to use this one of course, because its IID changes.
>>
> Could you set (temporarily) prefix for that address to /64 and
> re-run installer? IPA 4.3 has check that prevents you to use /128
> prefix
 Well now I don't even get asked for the IP. The setup wizard
 continues, but I now get this error:

   [27/43]: restarting directory server
 ipa : CRITICAL Failed to restart the directory server
 (Command '/bin/systemctl restart dirsrv@MY-REALM.service' returned
 non-zero exit status 1). See the installation log for details.
   [28/43]: setting up initial replication
   [error] error: [Errno 111] Connection refused

 LOG:
 2016-10-26T15:14:46Z DEBUG Process finished, return code=1
 2016-10-26T15:14:46Z DEBUG stdout=
 2016-10-26T15:14:46Z DEBUG stderr=Job for dirsrv@MY-REALM.service
 failed because the control process exited with error code. See
 "systemctl status dirsrv@MY-REALM.service" and "journalctl -xe" for
 details.
 2016-10-26T15:14:46Z CRITICAL Failed to restart the directory
 server (Command '/bin/systemctl restart dirsrv@MY-REALM.service'
 returned non-zero exit status 1). See the installation log for details.
 2016-10-26T15:14:46Z DEBUG   duration: 1 seconds
 2016-10-26T15:14:46Z DEBUG   [28/43]: setting up initial replication
 2016-10-26T15:14:56Z DEBUG Traceback (most recent call last):

 When I try to restart manually with, "/bin/systemctl restart
 dirsrv@MY-REALM.service"
  this is what systemd logs:
 https://paste.fedoraproject.org/461439/raw/


>>>
>>> Could you please check 

Re: [Freeipa-users] ipa-replica-install fails because of IPv6?

[Jochen Demmer]

Am 27.10.2016 um 10:02 schrieb Jochen Demmer:
>
>
> Am 26.10.2016 um 17:31 schrieb Martin Basti:
>>
>>
>>
>> On 26.10.2016 17:25, Jochen Demmer wrote:
>>>
>>>
>>> Am 26.10.2016 um 16:48 schrieb Martin Basti:



 On 26.10.2016 16:42, Jochen Demmer wrote:
>
>
> Am 26.10.2016 um 16:27 schrieb Martin Basti:
>>
>>
>>
>> On 26.10.2016 16:10, Jochen Demmer wrote:
>>> Hi,
>>>
>>> my answers also inline.
>>>
>>> Am 26.10.2016 um 15:38 schrieb Martin Basti:

 Hi, comments inline


 On 26.10.2016 14:28, Jochen Demmer wrote:
> Hi,
>
> I've been running and using a single FreeIPA server
> successfully, i.e.:
> Fedora 24
> freeipa-server-4.3.2-2.fc24.x86_64
> This server is only available via IPv6, because I can't get
> public lPv4 addresses no more.
>
> Now I want to setup a FreeIPA replica at another site also
> running IPv6, Fedora 24 and freeipa-server-4.3.2-2.fc24.x86_64
> First I run "ipa-client-install" which succeeds without an error.
> When I invoke "ipa-replica-install" I get this error:
> ipa : ERRORCould not resolve hostname
> *hostname.mydoma.in* using DNS. Clients may not function
> properly. Please check your DNS setup. (Note that this check
> queries IPA DNS directly and ignores /etc/hosts.)
> LOG:
> 2016-10-26T12:14:39Z DEBUG Search DNS server
> *hostname.mydoma.in* (['2a01:f11:1:1::1', '2a01:f11:1:1::1',
> '2a01:f11:1:1::1']) for *hostname.mydoma.in*

 Can you check with dig or host command if the hostname is
 really resolvable on that machine? do you have proper resolver
 in /etc/resolv.conf?
>>> There is a resolver given in /etc/resolv.conf. When I do "host
>>> <>" I get the right IPv6 back.
>> That is weird because IPA is doing basically the same.
>>

>
> *hostname.mydoma.in* is actually the DNS entry for the old
> FreeIPA server, which actually resolves, but only to an IPv6
> address of course.
> I can continue the installation though by entering "yes".
>
> I then get asked:
> Enter the IP address to use, or press Enter to finish.
> Please provide the IP address to be used for this host name:
>
> When I enter the IPv6 address of the new replica host it
> doesn't accept but infinitely asks this question instead.

 Have you pressed enter twice? It should end prompt and continue
 with installation
>>> Enter without an IP -> No usable IP address provided nor resolved.
>>> Enter with an IP -> Error: Invalid IP Address 2a02:1:2:3::4
>>> cannot use IP network address 2a02:1:2:3::4 
>>
>> How do you have configured IP address on your interface? Does it
>> have prefix /128?
> Yes, that's right. It's an IP being assigned statefully by a
> DHCPv6 server.
> There is also another dynamic IP within the same prefix having
> /64. I don't want to use this one of course, because its IID changes.
>
 Could you set (temporarily) prefix for that address to /64 and
 re-run installer? IPA 4.3 has check that prevents you to use /128
 prefix
>>> Well now I don't even get asked for the IP. The setup wizard
>>> continues, but I now get this error:
>>>
>>>   [27/43]: restarting directory server
>>> ipa : CRITICAL Failed to restart the directory server
>>> (Command '/bin/systemctl restart dirsrv@MY-REALM.service' returned
>>> non-zero exit status 1). See the installation log for details.
>>>   [28/43]: setting up initial replication
>>>   [error] error: [Errno 111] Connection refused
>>>
>>> LOG:
>>> 2016-10-26T15:14:46Z DEBUG Process finished, return code=1
>>> 2016-10-26T15:14:46Z DEBUG stdout=
>>> 2016-10-26T15:14:46Z DEBUG stderr=Job for dirsrv@MY-REALM.service
>>> failed because the control process exited with error code. See
>>> "systemctl status dirsrv@MY-REALM.service" and "journalctl -xe" for
>>> details.
>>> 2016-10-26T15:14:46Z CRITICAL Failed to restart the directory server
>>> (Command '/bin/systemctl restart dirsrv@MY-REALM.service' returned
>>> non-zero exit status 1). See the installation log for details.
>>> 2016-10-26T15:14:46Z DEBUG   duration: 1 seconds
>>> 2016-10-26T15:14:46Z DEBUG   [28/43]: setting up initial replication
>>> 2016-10-26T15:14:56Z DEBUG Traceback (most recent call last):
>>>
>>> When I try to restart manually with, "/bin/systemctl restart
>>> dirsrv@MY-REALM.service"
>>>  this is what systemd logs:
>>> https://paste.fedoraproject.org/461439/raw/
>>>
>>>
>>
>> Could you please check /var/log/dirsrv/slapd-*/errors  there might be
>> more details.
>>
>> Did you reused an old IPA server for this installation?
>>
>> Martin
> This is what the logfile says:
> 

Re: [Freeipa-users] FreeIPA domains and sub-domains

[Alexander Bokovoy]

On to, 27 loka 2016, Brian Candler wrote:

On 26/10/2016 21:03, Ranbir wrote:


If I have two networks, say A and B, and I want both to use the same 
FreeIPA server, should I have one Freeipa domain for network A and a 
sub-domain for network B, (domain.local and b.domain.local), or 
should I create two top level domains (a.local and b.local)? What's 
the recommended way to do this?


Well, as a first point, I'd say never use a fake domain like ".local". 
Use a subdomain of some real domain that you already have - e.g. 
int.yourcompany.com.  You don't need to expose it to the Internet if 
you don't want to, and a fake domain can cause you problems down the 
line.


Secondly: do you really need two domains? DNS domains are used as way 
to delegate administrative responsibility. If the same person is 
managing the DNS for both sites, then you can just as well use one 
domain.  Personally I like to embed the site in the hostname (e.g. 
lon-srv-1.int.yourcomany.com), because there are many circumstance in 
which only the shortened hostname "lon-srv-1" is seen, such as syslog 
messages and bash prompts. Hence it's good for the hostname itself to 
be unambiguous.


But if you prefer a different DNS domain for equipment in each site, 
that's not a problem either.  You can either create additional domains 
in FreeIPA (if you want to use the FreeIPA GUI/CLI to manage DNS 
records), or just have separate DNS domains managed elsewhere.  If 
FreeIPA is managing your DNS, you can get it to manage your reverse 
DNS too, by creating domains like 10.in-addr.arpa and 
168.192.in-addr.arpa.


Taking this to extreme: you don't even need to use the same DNS domain 
for your IPA and your other equipment. It's fine to have:


ldap-1.ipa.yourdomain.com
host1.site1.yourdomain.com
host2.site2.yourdomain.com

even if all the hosts are joined into the same Kerberos realm 
IPA.YOURDOMAIN.COM (which sounds like is what you're doing).


This is quite a good approach if you already have existing DNS for 
site1.yourdomain.com and site2.yourdomain.com which you don't want to 
change. Having FreeIPA manage its own domain makes it easier to 
automatically locate the Kerberos servers for the realm 
IPA.YOURDOMAIN.COM.  But even that's not necessary if you are happy to 
create the necessary SRV records in the DNS yourself.


The final issue is IPA replicas in multiple sites. Personally I've put 
all my IPA replicas in the same DNS domain 
(ldap-1.ipa.yourcompany.com; ldap-2.ipa.yourcompany.com), and have 
never tried putting them in different DNS domains: e.g.


ipa-1.site1.yourdomain.com
ipa-2.site2.yourdomain.com

I'm not sure if you can do this, and I think it would be safer not to 
unless someone else on this list says it's OK.

Yes, you can do that, there is no issue at all.
--
/ 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] rpm dependencies

[Alexander Bokovoy]

On to, 27 loka 2016, David Kupka wrote:

On 26/10/16 20:00, lejeczek wrote:

hi all

quick question - does IPA rpms depend on samaba's?
I'm hoping I can remove samba-common but dnf fies a 46 packages long
list of dependencies - is it somehow broken?
If is not and that is 100% correct long chain of deps - then can samba
be safely downgraded to 3.6.x ? given that IPA does not integrate samba
in my configuration.

many thanks
L.



Hello!

Only freeipa-server-trust-ad package depends on samba. If you haven't 
configured AD trust you can safely remove samba (and also 
freeipa-server-trust-ad package if you've installed it).
samba-common contains files for samba client and server so removing it 
may remove applications that can behave as samba client.

That's not fully correct. FreeIPA 4.2+ has 389-ds plugins which link to
Samba components and are part of freeipa-server package because we
configure them by default to make trust agent configuration easy:

# rpm -q --requires freeipa-server|grep ^lib|xargs -n1 rpm -q 
--whatprovides|sort -u
glibc-2.23.1-10.fc24.x86_64
krb5-libs-1.14.4-4.fc24.x86_64
libcom_err-1.42.13-4.fc24.x86_64
libgcc-6.2.1-2.fc24.x86_64
libsss_nss_idmap-1.14.2-1.fc24.x86_64
libtalloc-2.1.6-1.fc24.x86_64
libtevent-0.9.28-1.fc24.x86_64
libunistring-0.9.4-3.fc24.x86_64
libuuid-2.28.2-1.fc24.x86_64
libverto-0.2.6-6.fc24.x86_64
nspr-4.13.1-1.fc24.x86_64
nss-3.27.0-1.1.fc24.x86_64
nss-util-3.27.0-1.0.fc24.x86_64
openldap-2.4.44-1.fc24.x86_64
openssl-libs-1.0.2j-1.fc24.x86_64
samba-client-libs-4.4.6-1.fc24.x86_64

You cannot remove samba-client-libs due to this.

We also do not support downgrading Samba.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] ipa-replica-install fails because of IPv6?

[Jochen Demmer]

Am 26.10.2016 um 17:31 schrieb Martin Basti:
>
>
>
> On 26.10.2016 17:25, Jochen Demmer wrote:
>>
>>
>> Am 26.10.2016 um 16:48 schrieb Martin Basti:
>>>
>>>
>>>
>>> On 26.10.2016 16:42, Jochen Demmer wrote:


 Am 26.10.2016 um 16:27 schrieb Martin Basti:
>
>
>
> On 26.10.2016 16:10, Jochen Demmer wrote:
>> Hi,
>>
>> my answers also inline.
>>
>> Am 26.10.2016 um 15:38 schrieb Martin Basti:
>>>
>>> Hi, comments inline
>>>
>>>
>>> On 26.10.2016 14:28, Jochen Demmer wrote:
 Hi,

 I've been running and using a single FreeIPA server
 successfully, i.e.:
 Fedora 24
 freeipa-server-4.3.2-2.fc24.x86_64
 This server is only available via IPv6, because I can't get
 public lPv4 addresses no more.

 Now I want to setup a FreeIPA replica at another site also
 running IPv6, Fedora 24 and freeipa-server-4.3.2-2.fc24.x86_64
 First I run "ipa-client-install" which succeeds without an error.
 When I invoke "ipa-replica-install" I get this error:
 ipa : ERRORCould not resolve hostname
 *hostname.mydoma.in* using DNS. Clients may not function
 properly. Please check your DNS setup. (Note that this check
 queries IPA DNS directly and ignores /etc/hosts.)
 LOG:
 2016-10-26T12:14:39Z DEBUG Search DNS server
 *hostname.mydoma.in* (['2a01:f11:1:1::1', '2a01:f11:1:1::1',
 '2a01:f11:1:1::1']) for *hostname.mydoma.in*
>>>
>>> Can you check with dig or host command if the hostname is really
>>> resolvable on that machine? do you have proper resolver in
>>> /etc/resolv.conf?
>> There is a resolver given in /etc/resolv.conf. When I do "host
>> <>" I get the right IPv6 back.
> That is weird because IPA is doing basically the same.
>
>>>

 *hostname.mydoma.in* is actually the DNS entry for the old
 FreeIPA server, which actually resolves, but only to an IPv6
 address of course.
 I can continue the installation though by entering "yes".

 I then get asked:
 Enter the IP address to use, or press Enter to finish.
 Please provide the IP address to be used for this host name:

 When I enter the IPv6 address of the new replica host it
 doesn't accept but infinitely asks this question instead.
>>>
>>> Have you pressed enter twice? It should end prompt and continue
>>> with installation
>> Enter without an IP -> No usable IP address provided nor resolved.
>> Enter with an IP -> Error: Invalid IP Address 2a02:1:2:3::4
>> cannot use IP network address 2a02:1:2:3::4 
>
> How do you have configured IP address on your interface? Does it
> have prefix /128?
 Yes, that's right. It's an IP being assigned statefully by a DHCPv6
 server.
 There is also another dynamic IP within the same prefix having /64.
 I don't want to use this one of course, because its IID changes.

>>> Could you set (temporarily) prefix for that address to /64 and
>>> re-run installer? IPA 4.3 has check that prevents you to use /128 prefix
>> Well now I don't even get asked for the IP. The setup wizard
>> continues, but I now get this error:
>>
>>   [27/43]: restarting directory server
>> ipa : CRITICAL Failed to restart the directory server
>> (Command '/bin/systemctl restart dirsrv@MY-REALM.service' returned
>> non-zero exit status 1). See the installation log for details.
>>   [28/43]: setting up initial replication
>>   [error] error: [Errno 111] Connection refused
>>
>> LOG:
>> 2016-10-26T15:14:46Z DEBUG Process finished, return code=1
>> 2016-10-26T15:14:46Z DEBUG stdout=
>> 2016-10-26T15:14:46Z DEBUG stderr=Job for dirsrv@MY-REALM.service
>> failed because the control process exited with error code. See
>> "systemctl status dirsrv@MY-REALM.service" and "journalctl -xe" for
>> details.
>> 2016-10-26T15:14:46Z CRITICAL Failed to restart the directory server
>> (Command '/bin/systemctl restart dirsrv@MY-REALM.service' returned
>> non-zero exit status 1). See the installation log for details.
>> 2016-10-26T15:14:46Z DEBUG   duration: 1 seconds
>> 2016-10-26T15:14:46Z DEBUG   [28/43]: setting up initial replication
>> 2016-10-26T15:14:56Z DEBUG Traceback (most recent call last):
>>
>> When I try to restart manually with, "/bin/systemctl restart
>> dirsrv@MY-REALM.service"
>>  this is what systemd logs:
>> https://paste.fedoraproject.org/461439/raw/
>>
>>
>
> Could you please check /var/log/dirsrv/slapd-*/errors  there might be
> more details.
>
> Did you reused an old IPA server for this installation?
>
> Martin
This is what the logfile says:
https://paste.fedoraproject.org/461685/raw/

I tried to install this server as a replica a couple of times, but I
even reinstalled all of the software and I keep using
ipa-client-install --uninstall and

Re: [Freeipa-users] Is this a bigger Problem DNSSEC ?

[Petr Spacek]

On 25.10.2016 15:49, Günther J. Niederwimmer wrote:
> Hello,
> 
> FreeIPA 4.3.1
> CentOS 7.2
> 
> 
> I found today in /var/log/messages this entries 
> 
> Is the DNSSEC now broken ?
> 
> Thanks for a answer
> 
> ct 25 15:41:29 ipa ipa-dnskeysyncd: Traceback (most recent call last):
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/libexec/ipa/ipa-dnskeysyncd", 
> line 112, in 
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: while 
> ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib64/python2.7/site-
> packages/ldap/syncrepl.py", line 405, in syncrepl_poll
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.syncrepl_refreshdone()
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
> packages/ipapython/dnssec/keysyncer.py", line 118, in syncrepl_refreshdone
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.bindmgr.sync(self.dnssec_zones)
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
> packages/ipapython/dnssec/bindmgr.py", line 209, in sync
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.sync_zone(zone)
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
> packages/ipapython/dnssec/bindmgr.py", line 182, in sync_zone
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: self.install_key(zone, uuid, attrs, 
> tempdir)
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
> packages/ipapython/dnssec/bindmgr.py", line 117, in install_key
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: result = ipautil.run(cmd, 
> capture_output=True)
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: File "/usr/lib/python2.7/site-
> packages/ipapython/ipautil.py", line 479, in run
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: raise CalledProcessError(p.returncode, 
> arg_string, str(output))
> Oct 25 15:41:29 ipa ipa-dnskeysyncd: subprocess.CalledProcessError: Command 
> '/usr/sbin/dnssec-keyfromlabel-pkcs11 -K /var/named/dyndb-
> ldap/ipa/master/4gjn.com/tmppaO_R2 -a RSASHA256 -l 
> pkcs11:object=d7fe5c98d5f3f89aefb9e8dfb92ebcb1;pin-
> source=/var/lib/ipa/dnssec/softhsm_pin -I 20160811091542 -D 20160825225503 -P 
> 20160513081600 -A 20160513081600 4gjn.com.' returned non-zero exit status 1
> Oct 25 15:41:30 ipa systemd: ipa-dnskeysyncd.service: main process exited, 
> code=exited, status=1/FAILURE
> Oct 25 15:41:30 ipa systemd: Unit ipa-dnskeysyncd.service entered failed 
> state.
> Oct 25 15:41:30 ipa systemd: ipa-dnskeysyncd.service failed.

It might break in future, when keys are rotated.

Please follow
http://www.freeipa.org/page/Troubleshooting#DNSSEC_signing_does_not_work

This debugging option might get handy, too:
http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_returns_no_data


-- 
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] dns_tkey_negotiategss: failure GSSAPI error [...] Message stream modified.

[Petr Spacek]

On 27.10.2016 04:43, Tyrell Jentink wrote:
>> 2016-10-26T23:30:40Z DEBUG Writing nsupdate commands to
>> > /etc/ipa/.dns_update.txt:
>> > 2016-10-26T23:30:40Z DEBUG debug
>> >
>> > update delete trainmaster.ipa.rxrhouse.net. IN A
>> > show
>> > send
>> >
>> > update delete trainmaster.ipa.rxrhouse.net. IN 
>> > show
>> > send
>> >
>> > update add trainmaster.ipa.rxrhouse.net. 1200 IN A 10.42.0.100
>> > show
>> > send
>> >
>> > 2016-10-26T23:30:40Z DEBUG Starting external process
>> > 2016-10-26T23:30:40Z DEBUG args=/usr/bin/nsupdate -g
>> > /etc/ipa/.dns_update.txt
>> > 2016-10-26T23:30:40Z DEBUG Process finished, return code=1
>> > 2016-10-26T23:30:40Z DEBUG stdout=Outgoing update query:
>> > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
>> > ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
>> > ;; UPDATE SECTION:
>> > trainmaster.ipa.rxrhouse.net. 0 ANY A
>> >
>> > Outgoing update query:
>> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  39562
>> > ;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>> > ;; QUESTION SECTION:
>> > ;3107127915.sig-ipa-pdc.ipa.rxrhouse.net. ANY TKEY
>> >
>> > ;; ADDITIONAL SECTION:
>> > 3107127915.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig. 1477524640
[...]
>> >
>> > 2016-10-26T23:30:40Z DEBUG stderr=Reply from SOA query:
>> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  38738
>> > ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>> > ;; QUESTION SECTION:
>> > ;trainmaster.ipa.rxrhouse.net.  IN  SOA
>> >
>> > ;; AUTHORITY SECTION:
>> > ipa.rxrhouse.net.   0   IN  SOA ipa-pdc.ipa.rxrhouse.net.
>> > hostmaster.ipa.rxrhouse.net. 1477524446 3600 900 1209600 3600
>> >
>> > Found zone name: ipa.rxrhouse.net
>> > The master is: ipa-pdc.ipa.rxrhouse.net
>> > start_gssrequest
>> > Found realm from ticket: IPA.RXRHOUSE.NET
>> > send_gssrequest
>> > recvmsg reply from GSS-TSIG query
>> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  39562
>> > ;; flags: qr; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>> > ;; QUESTION SECTION:
>> > ;3107127915.sig-ipa-pdc.ipa.rxrhouse.net. ANY TKEY
>> >
>> > ;; ANSWER SECTION:
>> > 3107127915.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig. 1466301805
>> > 1466388205 3 NOERROR 101
>> > YGMGCSqGSIb3EgECAgMAflQwUqADAgEFoQMCAR6kERgPMjAxNjA2MTkw
>> > MjAzMjVapQUCAwHGkaYDAgEpqREbD0FELlJYUkhPVVNFLk5FVKoUMBKg
>> > AwIBAaELMAkbB2FkLXBkYyQ=
>> > 0
>> >
>> > dns_tkey_negotiategss: failure GSSAPI error: Major = Unspecified GSS
>> > failure.  Minor code may provide more information, Minor = Message stream
>> > modified.
>> >
>> > 2016-10-26T23:30:40Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g
>> > /etc/ipa/.dns_update.txt' returned non-zero exit status 1
>> > 2016-10-26T23:30:40Z ERROR Failed to update DNS records.
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: Query:
>> > trainmaster.ipa.rxrhouse.net IN A
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: No record.
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: Query:
>> > trainmaster.ipa.rxrhouse.net IN 
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: No record.
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: Query: 100.0.42.10.in-addr.arpa.
>> > IN PTR
>> > 2016-10-26T23:30:40Z DEBUG DNS resolver: No record.
>> > 2016-10-26T23:30:40Z WARNING Missing A/ record(s) for host
>> > trainmaster.ipa.rxrhouse.net: 10.42.0.100.
>> > 2016-10-26T23:30:40Z WARNING Missing reverse record(s) for address(es):
>> > 10.42.0.100.
>> >
> -- Full logs can be found here:  http://pastebin.com/90dG9Ffu
> 
>- For grins, I decided to test:
>kinit admin
>id admin
>getent passwd admin
>on the client, and all of those all made valid responses... So
>authentication is working, I just can't update DNS records.
> 
> 
> So that's what I've tried, and where I'm at...  My client machines running
> modern client software can NOT update DNS records, complaining about GSSAPI
> "Message Stream Modified" errors...  And I have no idea how to troubleshoot
> that... Any ideas?

Interesting, I haven't seen this one :-)

There is something fishy in GSSAPI negotiation between the client and DNS 
server.

I would try this (and watch out for suspicious messages along the way):

1) To be sure, please double-check that ipa-pdc.ipa.rxrhouse.net. resolves
(from the client) to correct IP address of IPA DNS server.

2) Verify that Kerberos ticket for the DNS server can be obtained:
$ kinit -k
$ kvno DNS/ipa-pdc.ipa.rxrhouse.net
$ klist  # it should list Kerberos ticket for ipa-pdc.ipa.rxrhouse.net

3) Create a plain text file with update message content:
cat > /tmp/dnsupdate <