Re: [Freeipa-users] New install, unsupported format?

[Standa Laznicka]

Hello,
I don't quite understand your situation - have the error happened during 
an addition of the host to the "ipaservers" group or during replica 
installation?


Certutil is a wonderful piece of software that returns 
"(SEC_ERROR_LEGACY_DATABASE)" in about 90% of most common cases but I 
have never seen an actual legacy database. Usually, this error means 
that the directory you're pointing the certutil tool to either does not 
exist or you don't have the permissions to read/write in this exact 
directory.


Cheers,
Standa

P.S.: I might have sent you this email twice because I am a bad person 
when it comes to the "Send" button, please reply to the email which has 
"freeipa-users" in CC :)


On 02/23/2017 10:38 PM, Steve Huston wrote:

I already had to do that previously to get other things to work; I had
solved it by changing line 582 of
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py from
"::1" to "localhost" before installing the server.  I did do this on
the to-be-promoted client as well, to no avail.

On Thu, Feb 23, 2017 at 4:25 PM, Rob Crittenden  wrote:

Steve Huston wrote:

Next stage of my testing was to make a replica of the FreeIPA server,
and I started by doing a 'yum install ipa-server' and then moved on to
adding the host to the ipaservers group.  This fails every time
however, with the error:

ipa: ERROR: cannot connect to
'https://ipa.astro.princeton.edu/ipa/json':
(SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old,
unsupported format.

Searches on this seem to turn up things like expired certificates, or
"reboot httpd" (I went ahead and rebooted the whole ipa server), but
nothing concrete.  Suggestions?  Everything (server and soon-to-be
replica) running RHEL7.3 with all updates.


See the workaround in https://fedorahosted.org/freeipa/ticket/6575#comment:9

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] Default domain for AD groups

[Alexander Bokovoy]

On to, 23 helmi 2017, Hanoz Elavia wrote:

Hello,

My FreeIPA clients and server are setup to use the AD domain as the
default. This is done using the default_domain_suffix parameter in the sssd
section of the sssd.conf file.

This works fine for users when we use ldapsearch but not so much for
groups. For e.g.:

ldapsearch -x -W -s sub -H 'ldap://ipa.server.com' -b
'cn=compat,dc=ipa,dc=server,dc=com' -D
'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' '(cn=
domaingr...@server.com)'

works fine but

ldapsearch -x -W -s sub -H 'ldap://ipa.server.com' -b
'cn=compat,dc=ipa,dc=server,dc=com' -D
'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com'
'(cn=domaingroup)'

won't work. However, the above will work fine for users. I'm using the

No, compat tree is designed to be used with fully-qualified groups and
users. There is no way around it.

--
/ 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] WARNING: Existing users or groups do not have a SID identifier assigned

[Alexander Bokovoy]

On to, 23 helmi 2017, Gady Notrica wrote:

Hello,

When setting up a trust between IPA and AD I am having the Warning
below. Question: Is this going to affect the users in Active Directory
if IPA sync back with AD?

winsync and trust are incompatible options. You are supposed to disable
winsync when switching to trust.

To your question, the attributes that would be added, aren't
synchronized back by winsync. Still, if you are switching from winsync
to trust, disable winsync first.



# ipa-adtrust-install

WARNING: 200 existing users or groups do not have a SID identifier assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin generate
the SID identifier for all these users. Please note, the in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1) man page
for details.

Do you want to run the ipa-sidgen task? [no]:



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



--
/ 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] integrated DNS vs external DNS

[Matrix]

No, integrated dns is an optional component of ipa,  even for ad integration. 


But without integrated DNS, you have to correctly configure all srv records by 
manual.


Matrix 


-- Original --
From: Iulian Roman 
Date: Thu,Feb 23,2017 09:16
To: freeipa-users 
Subject: Re: [Freeipa-users] integrated DNS vs external DNS-- 
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] Default domain for AD groups

[Hanoz Elavia]

Hello,

My FreeIPA clients and server are setup to use the AD domain as the
default. This is done using the default_domain_suffix parameter in the sssd
section of the sssd.conf file.

This works fine for users when we use ldapsearch but not so much for
groups. For e.g.:

ldapsearch -x -W -s sub -H 'ldap://ipa.server.com' -b
'cn=compat,dc=ipa,dc=server,dc=com' -D
'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com' '(cn=
domaingr...@server.com)'

works fine but

ldapsearch -x -W -s sub -H 'ldap://ipa.server.com' -b
'cn=compat,dc=ipa,dc=server,dc=com' -D
'uid=binduser,cn=users,cn=accounts,dc=ipa,dc=server,dc=com'
'(cn=domaingroup)'

won't work. However, the above will work fine for users. I'm using the
following:

AD: Windows 2008 R2
FreeIPA Server: 4.4.0-14
FreeIPA Client: 4.4.0-14
SSSD: 1.14.0-43
Linux version: CentOS 7.3 x64_86

The AD trust is setup with --enable-compat.

Regards,

Hanoz
-- 
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] WARNING: Existing users or groups do not have a SID identifier assigned

[Gady Notrica]

Hello,

When setting up a trust between IPA and AD I am having the Warning below. 
Question: Is this going to affect the users in Active Directory if IPA sync 
back with AD?

# ipa-adtrust-install

WARNING: 200 existing users or groups do not have a SID identifier assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin generate
the SID identifier for all these users. Please note, the in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1) man page
for details.

Do you want to run the ipa-sidgen task? [no]:
-- 
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] WARNING: Existing users or groups do not have a SID identifier assigned

[Gady Notrica]

Hello,

When setting up a trust between IPA and AD I am having the Warning below. 
Question: Is this going to affect the users in Active Directory if IPA sync 
back with AD?

Any help?

# ipa-adtrust-install

WARNING: 200 existing users or groups do not have a SID identifier assigned.
Installer can run a task to have ipa-sidgen Directory Server plugin generate
the SID identifier for all these users. Please note, the in case of a high
number of users and groups, the operation might lead to high replication
traffic and performance degradation. Refer to ipa-adtrust-install(1) man page
for details.

Do you want to run the ipa-sidgen task? [no]:

Thank you,

Gady
-- 
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] New install, unsupported format?

[Steve Huston]

I already had to do that previously to get other things to work; I had
solved it by changing line 582 of
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py from
"::1" to "localhost" before installing the server.  I did do this on
the to-be-promoted client as well, to no avail.

On Thu, Feb 23, 2017 at 4:25 PM, Rob Crittenden  wrote:
> Steve Huston wrote:
>> Next stage of my testing was to make a replica of the FreeIPA server,
>> and I started by doing a 'yum install ipa-server' and then moved on to
>> adding the host to the ipaservers group.  This fails every time
>> however, with the error:
>>
>> ipa: ERROR: cannot connect to
>> 'https://ipa.astro.princeton.edu/ipa/json':
>> (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old,
>> unsupported format.
>>
>> Searches on this seem to turn up things like expired certificates, or
>> "reboot httpd" (I went ahead and rebooted the whole ipa server), but
>> nothing concrete.  Suggestions?  Everything (server and soon-to-be
>> replica) running RHEL7.3 with all updates.
>>
>
> See the workaround in https://fedorahosted.org/freeipa/ticket/6575#comment:9
>
> rob



-- 
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
  Princeton University  |ICBM Address: 40.346344   -74.652242
345 Lewis Library   |"On my ship, the Rocinante, wheeling through
  Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'

-- 
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] New install, unsupported format?

[Rob Crittenden]

Steve Huston wrote:
> Next stage of my testing was to make a replica of the FreeIPA server,
> and I started by doing a 'yum install ipa-server' and then moved on to
> adding the host to the ipaservers group.  This fails every time
> however, with the error:
> 
> ipa: ERROR: cannot connect to
> 'https://ipa.astro.princeton.edu/ipa/json':
> (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old,
> unsupported format.
> 
> Searches on this seem to turn up things like expired certificates, or
> "reboot httpd" (I went ahead and rebooted the whole ipa server), but
> nothing concrete.  Suggestions?  Everything (server and soon-to-be
> replica) running RHEL7.3 with all updates.
> 

See the workaround in https://fedorahosted.org/freeipa/ticket/6575#comment:9

rob

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

[Freeipa-users] New install, unsupported format?

[Steve Huston]

Next stage of my testing was to make a replica of the FreeIPA server,
and I started by doing a 'yum install ipa-server' and then moved on to
adding the host to the ipaservers group.  This fails every time
however, with the error:

ipa: ERROR: cannot connect to
'https://ipa.astro.princeton.edu/ipa/json':
(SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old,
unsupported format.

Searches on this seem to turn up things like expired certificates, or
"reboot httpd" (I went ahead and rebooted the whole ipa server), but
nothing concrete.  Suggestions?  Everything (server and soon-to-be
replica) running RHEL7.3 with all updates.

-- 
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
  Princeton University  |ICBM Address: 40.346344   -74.652242
345 Lewis Library   |"On my ship, the Rocinante, wheeling through
  Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'

-- 
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] pki-tomcat will not start after certificate renewal

[Joseph Vandermas]

I got really busy sorry about the delay. It was a coworker who renewed our 
CA cert during an upgrade from Centos 6 to Centos 7. I remember him saying 
during the upgrade the CA broke and he had to mess around with it. 
According to him "Pretty sure I did the walk the clock back thing, but 
it's been so long I don't remember." As for pki-tomcat it certs where 
renewed automatically.


I have tried the work around that was suggested on the open bug and that 
did not fix my issue.


On Thu, 9 Feb 2017, Rob Crittenden wrote:


Joseph Vandermaas wrote:

All
I have been experiencing some issues with a FreeIPA instance that I 
maintain. More specifically pki-tomcat has not started since around the time 
it’s certificate renewed. I submitted this bug report 
https://fedorahosted.org/freeipa/ticket/6521, however a solution has yet to be 
found.
This installation does have one instresting issue that I believe may be 
causing it to fail. There are two certificates under cn=EXAMPLE.COM IPA 
CA,cn=certificates,cn=ipa,cn=etc,dc=example,dc=com. Both of these are valid CA 
certificates and when I run openssl verify with ether of them as the CA and the 
new subsystem certificate I get an OK message. I also believe that this issue 
is causing me not to be able to do a ipa-certupdate on the broken IPA server. 
Is there a way to to clean this up, should I try renewing the CA certificate 
and get rid of the old LDAP entries?



What did you do, as exactly as you can remember, to get the certificates
renewed?

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

[Freeipa-users] UPDATE: NOT Resolved After All -- sudo NOPASSWD for a single command

[Auerbach, Steven]

Yes, I implemented in Policy -> Sudo -> Sudo Commands as:
Sudo Command:  NOPASSWD: /sbin/vgs

The script (executed by a non-root, administrative group user on an enrolled 
host) specifies:
….
hostname >> statresults.txt
cat /etc/redhat-release >> statresults.txt
uname -r >> statresults.txt
printf "\n " >> statresults.txt
sudo vgs >> statresults.txt
…..
Running the script I still was prompted for a password.

RESEARCH AND CORRECTION:
In the sssd.conf file on the enrolled host I found an invalid pointer to 
“ipa_server=”  directive which I corrected and added sudo to the “services=” 
directive.  One or both of those changes corrected the situation and vgs runs 
under sudo without a password prompt.

FURTHER CORRECTION:
The sssd.conf changes did NOT resolve the issue.  The password must have been 
cached from a prior script run when I re-ran it. I am being prompted for 
password by the sudo line again.


From: Jason B. Nance [mailto:ja...@tresgeek.net]
Sent: Wednesday, February 22, 2017 11:59 AM
To: Auerbach, Steven 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo NOPASSWD for a single command


We have a script stored on a particular server in our realm that executes a 
number of non-privileged commands and are wanting to add /sbin/vgs command. The 
script uses SSH to then execute the same set of commands on all the servers in 
the realm.
The owner of the script is in the administrator group and there are sudoer 
commands for the administrator group in general.  We need to place a rule for 
this one command for either this group or the script owner to run NOPASSWD.
Where and how would I specify that in the IPA admin console?
Have you tried creating your command in IPA as "NOPASSWD: /sbin/vgs" (Policy -> 
Sudo -> Sudo Commands)?

-- 
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] authenticating with dns

[Aaron Young]

And yes, I learned to stop using kadmin after I made that note

On Thu, Feb 23, 2017 at 11:56 AM, Aaron Young 
wrote:

> on ld4ipa01, I removed it with ipa-server-install --uninstall
>
> this was an attempt to recreate the replica from nyc02ipa02
>
> On Thu, Feb 23, 2017 at 3:17 AM, Martin Basti  wrote:
>
>>
>>
>> On 22.02.2017 23:26, Aaron Young wrote:
>>
>> Hello Everyone
>>
>> I recently lost the master master IPA server setup by the previous
>> administrator.
>> As it stands now, if I try to add a new client, in order to standup a new
>> replica, I get errors while trying to setup DNS. This led me to look at how
>> authentication worked (I'm new to IPA) and I learned about the kerberos
>> tools
>>
>> I don't know if I'm familiar enough with the terminology to adequately
>> describe what I'm experiencing, so I'll give you some of the commands and
>> their results
>>
>> but first, a bit on the design
>>
>> before I got to this, we had
>>
>> a <-> b <-> c <-> d
>>
>> b was the master master
>>
>> a, happened to point to two test servers nyc02ipa01 and nyc02ipa02 (not
>> pictured, I discovered them later when c and d started having problems)
>>
>> a - nyc01ipa02
>> b - nyc01ipa01
>> c - ld4ipa01
>> d - ld4ipa02
>>
>> currently, I have nyc02ipa02 <-> nyc01ipa02
>>
>> the reason I have it limited like this is because all the other servers
>> stopped replicating for one reason or another (mainly that they can't
>> authenticate or in one case, there was a database record corruption)
>>
>> Anyway, here are some activities and logs from the latest round of fixes
>> and information activities I've been engaging in
>>
>> 22:54:32 root@nyc01ipa02:~# kinit admin
>> kinit: Clients credentials have been revoked while getting initial
>> credentials
>>
>> Reading through this
>>  tells me
>> that
>>
>> # kadmin: modprinc -unlock PRINCNAME
>>
>> will unlock an account...but if I can't get in
>>
>> 22:54:37 root@nyc01ipa02:~# kadmin
>> Authenticating as principal root/admin@MF with password.
>> kadmin: Client 'root/admin@MF' not found in Kerberos database while
>> initializing kadmin interface
>>
>> on ld4ipa02, did a
>>
>> # ipa-client-install --uninstall
>>
>> then
>>
>> # ipa-client-install --force-join --enable-dns-updates --permit -f
>> --ssh-trust-dns --request-cert --automount-location=LD4 --enable-dns-updates
>>
>> DNS did not update, here is the relevant portion from
>> /var/log/ipaclient-install.log
>>
>> 2017-02-20T18:46:49Z DEBUG Writing nsupdate commands to 
>> /etc/ipa/.dns_update.txt:
>> 2017-02-20T18:46:49Z DEBUG debug
>>
>> update delete ld4ipa02.mf. IN A
>> show
>> send
>>
>> update delete ld4ipa02.mf. IN 
>> show
>> send
>>
>> update add ld4ipa02.mf. 1200 IN A 10.102.100.140
>> show
>> send
>>
>> 2017-02-20T18:46:49Z DEBUG Starting external process
>> 2017-02-20T18:46:49Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt
>> 2017-02-20T18:46:49Z DEBUG Process finished, return code=1
>> 2017-02-20T18:46:49Z DEBUG stdout=Outgoing update query:
>> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
>> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
>> ;; UPDATE SECTION:
>> ld4ipa02.mf. 0 ANY A
>>
>> 2017-02-20T18:46:49Z DEBUG stderr=Reply from SOA query:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34702
>> ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>> ;; QUESTION SECTION:
>> ;ld4ipa02.mf. IN SOA
>>
>> ;; AUTHORITY SECTION:
>> mf. 1800 IN SOA ld4ipa01.mf. hostmaster.mf. 1487615509 3600 900 1209600 3600
>>
>> Found zone name: mf
>> The master is: ld4ipa01.mf
>> start_gssrequest
>> tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code 
>> may provide more information, Minor = Server DNS/ld4ipa01.mf@MF not found in 
>> Kerberos database.
>>
>> 2017-02-20T18:46:49Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g 
>> /etc/ipa/.dns_update.txt' returned non-zero exit status 1
>> 2017-02-20T18:46:49Z ERROR Failed to update DNS records.
>> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN A
>> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
>> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN 
>> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
>> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: 140.100.102.10.in-addr.arpa. 
>> IN PTR
>> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
>> 2017-02-20T18:46:49Z WARNING Missing A/ record(s) for host ld4ipa02.mf: 
>> 10.102.100.140.
>> 2017-02-20T18:46:49Z WARNING Missing reverse record(s) for address(es): 
>> 10.102.100.140.
>>
>> Why isn't there an entry for "DNS/ld4ipa01.mf@MF" in the Kerberos
>> database?
>>
>> klist -ktK /etc/dirsrv/ds.keytab on ld4ipa01 returns
>>
>> Keytab name: FILE:/etc/dirsrv/ds.keytab
>> 
>> KVNO Timestamp Principal
>>  --- 

Re: [Freeipa-users] authenticating with dns

[Aaron Young]

on ld4ipa01, I removed it with ipa-server-install --uninstall

this was an attempt to recreate the replica from nyc02ipa02

On Thu, Feb 23, 2017 at 3:17 AM, Martin Basti  wrote:

>
>
> On 22.02.2017 23:26, Aaron Young wrote:
>
> Hello Everyone
>
> I recently lost the master master IPA server setup by the previous
> administrator.
> As it stands now, if I try to add a new client, in order to standup a new
> replica, I get errors while trying to setup DNS. This led me to look at how
> authentication worked (I'm new to IPA) and I learned about the kerberos
> tools
>
> I don't know if I'm familiar enough with the terminology to adequately
> describe what I'm experiencing, so I'll give you some of the commands and
> their results
>
> but first, a bit on the design
>
> before I got to this, we had
>
> a <-> b <-> c <-> d
>
> b was the master master
>
> a, happened to point to two test servers nyc02ipa01 and nyc02ipa02 (not
> pictured, I discovered them later when c and d started having problems)
>
> a - nyc01ipa02
> b - nyc01ipa01
> c - ld4ipa01
> d - ld4ipa02
>
> currently, I have nyc02ipa02 <-> nyc01ipa02
>
> the reason I have it limited like this is because all the other servers
> stopped replicating for one reason or another (mainly that they can't
> authenticate or in one case, there was a database record corruption)
>
> Anyway, here are some activities and logs from the latest round of fixes
> and information activities I've been engaging in
>
> 22:54:32 root@nyc01ipa02:~# kinit admin
> kinit: Clients credentials have been revoked while getting initial
> credentials
>
> Reading through this
>  tells me
> that
>
> # kadmin: modprinc -unlock PRINCNAME
>
> will unlock an account...but if I can't get in
>
> 22:54:37 root@nyc01ipa02:~# kadmin
> Authenticating as principal root/admin@MF with password.
> kadmin: Client 'root/admin@MF' not found in Kerberos database while
> initializing kadmin interface
>
> on ld4ipa02, did a
>
> # ipa-client-install --uninstall
>
> then
>
> # ipa-client-install --force-join --enable-dns-updates --permit -f
> --ssh-trust-dns --request-cert --automount-location=LD4 --enable-dns-updates
>
> DNS did not update, here is the relevant portion from
> /var/log/ipaclient-install.log
>
> 2017-02-20T18:46:49Z DEBUG Writing nsupdate commands to 
> /etc/ipa/.dns_update.txt:
> 2017-02-20T18:46:49Z DEBUG debug
>
> update delete ld4ipa02.mf. IN A
> show
> send
>
> update delete ld4ipa02.mf. IN 
> show
> send
>
> update add ld4ipa02.mf. 1200 IN A 10.102.100.140
> show
> send
>
> 2017-02-20T18:46:49Z DEBUG Starting external process
> 2017-02-20T18:46:49Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt
> 2017-02-20T18:46:49Z DEBUG Process finished, return code=1
> 2017-02-20T18:46:49Z DEBUG stdout=Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
> ;; UPDATE SECTION:
> ld4ipa02.mf. 0 ANY A
>
> 2017-02-20T18:46:49Z DEBUG stderr=Reply from SOA query:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34702
> ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;ld4ipa02.mf. IN SOA
>
> ;; AUTHORITY SECTION:
> mf. 1800 IN SOA ld4ipa01.mf. hostmaster.mf. 1487615509 3600 900 1209600 3600
>
> Found zone name: mf
> The master is: ld4ipa01.mf
> start_gssrequest
> tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code 
> may provide more information, Minor = Server DNS/ld4ipa01.mf@MF not found in 
> Kerberos database.
>
> 2017-02-20T18:46:49Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g 
> /etc/ipa/.dns_update.txt' returned non-zero exit status 1
> 2017-02-20T18:46:49Z ERROR Failed to update DNS records.
> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN A
> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN 
> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
> 2017-02-20T18:46:49Z DEBUG DNS resolver: Query: 140.100.102.10.in-addr.arpa. 
> IN PTR
> 2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
> 2017-02-20T18:46:49Z WARNING Missing A/ record(s) for host ld4ipa02.mf: 
> 10.102.100.140.
> 2017-02-20T18:46:49Z WARNING Missing reverse record(s) for address(es): 
> 10.102.100.140.
>
> Why isn't there an entry for "DNS/ld4ipa01.mf@MF" in the Kerberos
> database?
>
> klist -ktK /etc/dirsrv/ds.keytab on ld4ipa01 returns
>
> Keytab name: FILE:/etc/dirsrv/ds.keytab 
> KVNO Timestamp Principal
>  --- --
> 
> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF (0x696a502bc73d209acdd36c42242f
> 7f8aff9dbba1073b34ea018ed3bd9cdfd970)
> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF (0xe031464b6948ea34f4291d40fca7
> a21e)
> 2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF 

[Freeipa-users] UPDATE: Resolved sudo NOPASSWD for a single command

[Auerbach, Steven]

Yes, I implemented in Policy -> Sudo -> Sudo Commands as:
Sudo Command:  NOPASSWD: /sbin/vgs

The script (executed by a non-root, administrative group user on an enrolled 
host) specifies:
….
hostname >> statresults.txt
cat /etc/redhat-release >> statresults.txt
uname -r >> statresults.txt
printf "\n " >> statresults.txt
sudo vgs >> statresults.txt
…..
Running the script I still was prompted for a password.

RESEARCH AND CORRECTION:
In the sssd.conf file on the enrolled host I found an invalid pointer to 
“ipa_server=”  directive which I corrected and added sudo to the “services=” 
directive.  One or both of those changes corrected the situation and vgs runs 
under sudo without a password prompt.

From: Jason B. Nance [mailto:ja...@tresgeek.net]
Sent: Wednesday, February 22, 2017 11:59 AM
To: Auerbach, Steven 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo NOPASSWD for a single command


We have a script stored on a particular server in our realm that executes a 
number of non-privileged commands and are wanting to add /sbin/vgs command. The 
script uses SSH to then execute the same set of commands on all the servers in 
the realm.
The owner of the script is in the administrator group and there are sudoer 
commands for the administrator group in general.  We need to place a rule for 
this one command for either this group or the script owner to run NOPASSWD.
Where and how would I specify that in the IPA admin console?
Have you tried creating your command in IPA as "NOPASSWD: /sbin/vgs" (Policy -> 
Sudo -> Sudo Commands)?

-- 
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] Recall: sudo NOPASSWD for a single command

[Auerbach, Steven]

Auerbach, Steven would like to recall the message, "[Freeipa-users] sudo 
NOPASSWD for a single command".

-- 
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] ldapsearch for AD users

[Hanoz Elavia]

Thanks Alexander,

I have rebuilt the server with compatibility and I can now query AD users.
I'll just have to confirm with Dell / EMC whether the Isilon can now handle
this.

Regards,

Hanoz


On Wed, Feb 22, 2017 at 10:26 PM, Alexander Bokovoy 
wrote:

> On ke, 22 helmi 2017, Jason B. Nance wrote:
>
>> For example, for user that would be (&(objectClass=posixAccount)(uid=%s))
>>> where %s is ad_u...@server.com according to your example.
>>>
>>> This is what would be intercepted and queried through SSSD.
>>>
>>> For example:
>>>
>>> $ ldapsearch -Y GSSAPI -b cn=compat,dc=xs,dc=ipa,dc=cool
>>> '(&(objectClass=posixAccount)(uid=u...@ad.ipa.cool))'
>>> SASL/GSSAPI authentication started
>>> SASL username: ad...@xs.ipa.cool
>>> SASL SSF: 56
>>> SASL data security layer installed.
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base 

[Freeipa-users] FreeIPA 4.4 / Winsync issues.

[Devin Acosta]

I have installed a new replica in our IPA domain and configured it to do a
winsync with Windows 2012R2. It creates the agreement but then after a
while it dies. It appears something isn't configured just right. The
Windows client is using the passync user on my side, and i'm creating the
sync using a windows account that has the appopriate permissions.


This is what I see after about 10 minutes of the sync running from the
server side.

[22/Feb/2017:23:43:33.103632587 +] agmt="cn=
meTolas01-050-005.axi.mtech.int" (las01-050-005:389) - Can't locate CSN
58ae22550018 in the changelog (DB rc=-30988). If replication stops,
the consumer may need to be reinitialized.
[22/Feb/2017:23:43:33.105866800 +] NSMMReplicationPlugin - changelog
program - agmt="cn=meTolas01-050-005.axi.mtech.int" (las01-050-005:389):
CSN 58ae22550018 not found, we aren't as up to date, or we purged
[22/Feb/2017:23:43:33.107971862 +] NSMMReplicationPlugin - windows sync
- agmt="cn=meTolas01-050-005.axi.mtech.int" (las01-050-005:389): Data
required to update replica has been purged. The replica must be
reinitialized.
[22/Feb/2017:23:43:33.109455154 +] NSMMReplicationPlugin - windows sync
- agmt="cn=meTolas01-050-005.axi.mtech.int" (las01-050-005:389):
Incremental update failed and requires administrator action

On the Windows Side, we show either DSA is unwilling to perform, or
Insufficient access. We are using the passsync user that was created during
the sync.

02/21/17 15:25:20: PassSync service initialized
02/21/17 15:25:20: PassSync service running
02/21/17 15:25:20: dataFilename is C:\Windows\System32\passhook.dat
02/21/17 15:25:20: 1 new entries loaded from data file
02/21/17 15:25:20: Cleared contents of data file
02/21/17 15:25:20: Password list has 1 entries
02/21/17 15:25:20: Ldap bind error in Connect
53: DSA is unwilling to perform
02/21/17 15:25:20: Attempting to sync password for jeremiah.pedersen
02/21/17 15:25:20: Searching for (uid=jeremiah.pedersen)
02/21/17 15:25:20: Password match, no modify performed: jeremiah.pedersen
02/21/17 15:25:20: Removing password change from list
02/21/17 15:25:20: Password list is empty.  Waiting for passhook event
02/21/17 17:19:42: Received passhook event.  Attempting sync
02/21/17 17:19:42: 1 new entries loaded from data file
02/21/17 17:19:42: Cleared contents of data file
02/21/17 17:19:42: Password list has 1 entries
02/21/17 17:19:42: Ldap bind error in Connect
53: DSA is unwilling to perform
02/21/17 17:19:42: Attempting to sync password for jeremiah
02/21/17 17:19:42: Searching for (uid=jeremiah)
02/21/17 17:19:42: Password match, no modify performed: jeremiah
02/21/17 17:19:42: Removing password change from list
02/21/17 17:19:42: Password list is empty.  Waiting for passhook event
02/22/17 05:05:15: Received passhook event.  Attempting sync
02/22/17 05:05:15: 1 new entries loaded from data file
02/22/17 05:05:15: Cleared contents of data file
02/22/17 05:05:15: Password list has 1 entries
02/22/17 05:05:15: Ldap bind error in Connect
53: DSA is unwilling to perform
02/22/17 05:05:15: Attempting to sync password for ray
02/22/17 05:05:15: Searching for (uid=ray)
02/22/17 05:05:15: Ldap error in ModifyPassword
50: Insufficient access
02/22/17 05:05:15: Modify password failed for remote entry:
uid=ray,cn=users,cn=accounts,dc=lxi,dc=mtech,dc=int
02/22/17 05:05:15: Deferring password change for ray
02/22/17 05:05:15: Backing off for 2000ms
02/22/17 05:05:17: Backoff time expired.  Attempting sync
02/22/17 05:05:17: Password list has 1 entries
02/22/17 05:05:17: Ldap bind error in Connect
53: DSA is unwilling to perform
02/22/17 05:05:17: Attempting to sync password for ray
02/22/17 05:05:17: Searching for (uid=ray)
02/22/17 05:05:17: Ldap error in ModifyPassword
50: Insufficient access
02/22/17 05:05:17: Modify password failed for remote entry:
uid=ray,cn=users,cn=accounts,dc=lxi,dc=mtech,dc=int
02/22/17 05:05:17: Deferring password change for ray
02/22/17 05:05:17: Backing off for 4000ms
02/22/17 05:05:21: Backoff time expired.  Attempting sync
02/22/17 05:05:21: Password list has 1 entries
02/22/17 05:05:21: Ldap bind error in Connect
53: DSA is unwilling to perform
02/22/17 05:05:21: Attempting to sync password for ray
02/22/17 05:05:21: Searching for (uid=ray)
02/22/17 05:05:21: Ldap error in ModifyPassword
50: Insufficient access
02/22/17 05:05:21: Modify password failed for remote entry:
uid=ray,cn=users,cn=accounts,dc=lxi,dc=mtech,dc=int
02/22/17 05:05:21: Deferring password change for ray
02/22/17 05:05:21: Backing off for 8000ms
02/22/17 05:05:29: Backoff time expired.  Attempting sync
02/22/17 05:05:29: Password list has 1 entries
02/22/17 05:05:29: Ldap bind error in Connect
53: DSA is unwilling to perform

Any help would greatly be appreciated.
-- 
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] integrated DNS vs external DNS

[Martin Basti]

Hello,

comments inline


On 23.02.2017 15:07, Iulian Roman wrote:
Despite reading the freeipa and Redhat IdM documentation regarding the 
DNS , it is still unclear to me if and when is integrated DNS 
mandatory .  We do have an environment with a pretty complex DNS setup 
, which is in place for years and there are no  plans to change it.


Integrated DNS is not mandatory at all. Without IPA DNS you have to 
manage all IPA system records manually on external DNS




if i understood correctly from the documentation , integrated DNS is 
mandatory for configuring AD trust. is that correct ?

No, it is not needed for AD trust, you need to add additional DNS records



Can the integrated DNS be configured as forward only ? Do the clients 
need to have IPA DNS as a resolver or they can just use existing DNS 
server ?

You don't need to install IPA DNS.

All records the IPA needs can be received from command `ipa 
dns-update-system-records --dry-run` (IPA4.4+)









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

Re: [Freeipa-users] sudo NOPASSWD for a single command

[Brendan Kearney]

On 02/23/2017 09:43 AM, Auerbach, Steven wrote:

sudo vgs >> statresults.txt


should be sudo /sbin/vgs >> statresults.txt since that is what sudo 
allows.  its almost like exact match for strings.


-- 
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] Recommended approach to VM snapshot prior to upgrade

[Rob Crittenden]

Martin Basti wrote:
> 
> 
> On 23.02.2017 00:47, Brian Mathis wrote:
>> I have a 3-node cluster running FreeIPA 4.2 on RHEL 7.2.  I would like
>> to upgrade to RHEL 7.3 / IPA 4.4, and I want to make VM snapshots that
>> I can rollback to in case there are issues.  What is the recommended
>> approach to this?
>>
>> Should services already be started when running the yum update?
> It doesn't matter, updater will stop/start services as needed
> 
>>
>> Can I shut down each ipa service one by one, snapshot, then upgrade? 
>> How would replication be affected if I had to rollback to the older
>> snapshot after other nodes had been upgraded?
> You have to rollback all snapshots for the whole topology and then you
> can start IPA, otherwise replication conflicts may happen.
> So I suggest to have snapshots of all servers before upgrade.
>>
>> Or is it better to shut down all ipa services on all nodes, make
>> snapshots, then perform the upgrade?  Obviously that would bring down
>> the domain during the upgrade, but it would better ensure integrity.
> This is the best for integrity, but in case there is no/low activity on
> servers, then one by one snapshots may work too.

I prefer the shut them all down method if you want a way to get back to
the pre-upgraded state.

Updating one of the masters is going to replicate out a bunch of
changes, so if something goes wrong and you restore that snapshot those
updates have already been replicated out. Would this cause problems?
Ideally no, but you wouldn't have the pre-upgrade systems either.

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] Can mount NFS, but user only gets the permission question marks

[Brendan Kearney]

On 02/23/2017 09:11 AM, Kees Bakker wrote:

On 23-02-17 13:51, Brendan Kearney wrote:

On 02/23/2017 07:32 AM, Kees Bakker wrote:

On 22-02-17 17:33, Brendan Kearney wrote:

On 02/22/2017 10:26 AM, Kees Bakker wrote:

On 22-02-17 14:05, Brendan Kearney wrote:

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So, 
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

The mount command is simple.
$ sudo mount -v -t nfs srv1.example.com:/home /nfshome
mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
mount.nfs: trying text-based options 
'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo mount |grep nfs
srv1.example.com:/home on /nfshome type nfs4 
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d?   ? ??   ?? nfshome


sec=krb* means that the user accessing the mount has to authenticate with a 
kerberos ticket, and has to be the user or in the group granted access to the 
share.  from the looks of things, the user did not authenticate, and that is 
why the permissions are question marks.  check the kerberos tickets that the 
user has (klist output).  Otherwise, the ownership might be user and group that 
the client machine does not recognize (think posix user/group that is not in 
sync between the NFS server and the client)

Thanks for the reply.

In this case the user _is_ authenticated.
keesb@client1:~$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: ke...@example.com

Valid starting ExpiresService principal
22-02-17 09:20:30  23-02-17 09:20:25  krbtgt/example@example.com

no, the user has a TGT.  a nfs/host.domain.tld@REALM ticket is needed to 
authenticate.

(( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. ))


What other grants could be needed? HBAC Rules?

Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's 
say so [2]. Anyway, it
doesn't help to get access for the user.)

there are principals to create and keytabs to be updated on hte NFS sever, if 
not done already.

I did create a principal for the NFS server (using ipa service-add) and
add to the keytab on the NFS server (using ipa-getkeytab) ...
root@srv1# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
 --
  1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96)
  1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96)
  1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96)
  1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96)

Is this what you mean?

yes, if that is done, the server side components should be done for kerberos.  
have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup?

I don't think that a change of idmapd.conf (on the NFS server) is needed 
because all host
names are FQDN and everything is in one and the same REALM.

NFS needs to know how to map a user object to an ID and groups. identities 
established by kerberos do not directly translate to users.  usually some sort 
of directory services are leveraged in order to accomplish this, though PAM and 
things like that can be used to.  by setting things in idmapd.conf, you are 
telling NFS who to translate kerberos identities into usernames, so ownership 
and permissions can be sync'd.

Both the NFS server and the client are configured as FreeIPA client.
On the server the users are known (through PAM, SSSD). Only user
"ubuntu" is a local (/etc/passwd) user. All other users are defined on
the IPA server.

root@srv1:~# ls -l /home
total 0
drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb
drwxr-xr-x 1 ubuntu ubuntu 142 aug 17  2016 ubuntu
root@srv1:~# ls -ln /home
total 0
drwxr-xr-x 1 60001 60001 116 jan 27 12:56 keesb
drwxr-xr-x 1  1000  1000 142 aug 17  2016 ubuntu

On the client, same story

root@client1:~# ls -l /nfshome
total 0
drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb
drwxr-xr-x 1 ubuntu  ubuntu  142 aug 17  2016 ubuntu
root@client1:~# ls -ln /nfshome

Re: [Freeipa-users] sudo NOPASSWD for a single command

[Auerbach, Steven]

Yes, I implemented in Policy -> Sudo -> Sudo Commands as:
Sudo Command:  NOPASSWD: /sbin/vgs

The script (executed by a non-root, administrative group user on an enrolled 
host) specifies:
….
hostname >> statresults.txt
cat /etc/redhat-release >> statresults.txt
uname -r >> statresults.txt
printf "\n " >> statresults.txt
sudo vgs >> statresults.txt
…..
Running the script I still was prompted for a password. So I guess this does 
not work.

From: Jason B. Nance [mailto:ja...@tresgeek.net]
Sent: Wednesday, February 22, 2017 11:59 AM
To: Auerbach, Steven 
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo NOPASSWD for a single command


We have a script stored on a particular server in our realm that executes a 
number of non-privileged commands and are wanting to add /sbin/vgs command. The 
script uses SSH to then execute the same set of commands on all the servers in 
the realm.
The owner of the script is in the administrator group and there are sudoer 
commands for the administrator group in general.  We need to place a rule for 
this one command for either this group or the script owner to run NOPASSWD.
Where and how would I specify that in the IPA admin console?
Have you tried creating your command in IPA as "NOPASSWD: /sbin/vgs" (Policy -> 
Sudo -> Sudo Commands)?

-- 
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] Can mount NFS, but user only gets the permission question marks

[Kees Bakker]

On 23-02-17 13:51, Brendan Kearney wrote:
> On 02/23/2017 07:32 AM, Kees Bakker wrote:
>> On 22-02-17 17:33, Brendan Kearney wrote:
>>> On 02/22/2017 10:26 AM, Kees Bakker wrote:
 On 22-02-17 14:05, Brendan Kearney wrote:
> On 02/22/2017 05:23 AM, Kees Bakker wrote:
>> On 21-02-17 19:49, Brendan Kearney wrote:
>>> On 02/21/2017 10:57 AM, Kees Bakker wrote:
 Hey,

 Maybe one of the NFS users on this list could give me a hint what
 could be wrong. I'm not sure if it has any relation with 
 FreeIPA/Kerberos.

 I've set up an NFS server and I can mount the NFS directory on my 
 client. So, I'm
 guessing that setting up Kerberos principal was done correctly.

 However, only root can actually access the mounted contents. Any other 
 user
 only sees question marks as shown below.

 The mount command is simple.
 $ sudo mount -v -t nfs srv1.example.com:/home /nfshome
 mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
 mount.nfs: trying text-based options 
 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'

 On the server side /etc/exports looks like this.
 /home*(rw,sync,sec=krb5i,no_subtree_check)

 $ sudo mount |grep nfs
 srv1.example.com:/home on /nfshome type nfs4 
 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)

 $ sudo ls -ld /nfshome
 drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
 $ sudo ls -l /nfshome
 total 0
 drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb

 $ ls -l /nfshome
 ls: cannot access '/nfshome': Permission denied
 $ ls -l / | grep nfshome
 ls: cannot access '/nfshome': Permission denied
 d?   ? ??   ?? nfshome

>>> sec=krb* means that the user accessing the mount has to authenticate 
>>> with a kerberos ticket, and has to be the user or in the group granted 
>>> access to the share.  from the looks of things, the user did not 
>>> authenticate, and that is why the permissions are question marks.  
>>> check the kerberos tickets that the user has (klist output).  
>>> Otherwise, the ownership might be user and group that the client 
>>> machine does not recognize (think posix user/group that is not in sync 
>>> between the NFS server and the client)
>> Thanks for the reply.
>>
>> In this case the user _is_ authenticated.
>> keesb@client1:~$ klist
>> Ticket cache: KEYRING:persistent:60001:60001
>> Default principal: ke...@example.com
>>
>> Valid starting ExpiresService principal
>> 22-02-17 09:20:30  23-02-17 09:20:25  krbtgt/example@example.com
> no, the user has a TGT.  a nfs/host.domain.tld@REALM ticket is needed to 
> authenticate.
 (( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. ))

>> What other grants could be needed? HBAC Rules?
>>
>> Do I need an nfs principal for the client? (I didn't think so, but many 
>> HOWTO's say so [2]. Anyway, it
>> doesn't help to get access for the user.)
> there are principals to create and keytabs to be updated on hte NFS 
> sever, if not done already.
 I did create a principal for the NFS server (using ipa service-add) and
 add to the keytab on the NFS server (using ipa-getkeytab) ...
 root@srv1# klist -ke
 Keytab name: FILE:/etc/krb5.keytab
 KVNO Principal
  
 --
  1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96)
  1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96)
  1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96)
  1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96)

 Is this what you mean?
>>> yes, if that is done, the server side components should be done for 
>>> kerberos.  have you set things up in /etc/idmapd.conf so your domain, 
>>> REALM, etc are setup?
>> I don't think that a change of idmapd.conf (on the NFS server) is needed 
>> because all host
>> names are FQDN and everything is in one and the same REALM.
> NFS needs to know how to map a user object to an ID and groups. identities 
> established by kerberos do not directly translate to users.  usually some 
> sort of directory services are leveraged in order to accomplish this, though 
> PAM and things like that can be used to.  by setting things in idmapd.conf, 
> you are telling NFS who to translate kerberos identities into usernames, so 
> ownership and permissions can be sync'd.

Both the NFS server and the client are configured as FreeIPA client.
On the server 

[Freeipa-users] integrated DNS vs external DNS

[Iulian Roman]

Despite reading the freeipa and Redhat IdM documentation regarding the DNS
, it is still unclear to me if and when is integrated DNS mandatory .  We
do have an environment with a pretty complex DNS setup , which is in place
for years and there are no  plans to change it.

if i understood correctly from the documentation , integrated DNS is
mandatory for configuring AD trust. is that correct ?

Can the integrated DNS be configured as forward only ? Do the clients need
to have IPA DNS as a resolver or they can just use existing DNS server ?
-- 
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] Can mount NFS, but user only gets the permission question marks

[Brendan Kearney]

On 02/23/2017 07:32 AM, Kees Bakker wrote:

On 22-02-17 17:33, Brendan Kearney wrote:

On 02/22/2017 10:26 AM, Kees Bakker wrote:

On 22-02-17 14:05, Brendan Kearney wrote:

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So, 
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

The mount command is simple.
$ sudo mount -v -t nfs srv1.example.com:/home /nfshome
mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
mount.nfs: trying text-based options 
'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo mount |grep nfs
srv1.example.com:/home on /nfshome type nfs4 
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d?   ? ??   ?? nfshome


sec=krb* means that the user accessing the mount has to authenticate with a 
kerberos ticket, and has to be the user or in the group granted access to the 
share.  from the looks of things, the user did not authenticate, and that is 
why the permissions are question marks.  check the kerberos tickets that the 
user has (klist output).  Otherwise, the ownership might be user and group that 
the client machine does not recognize (think posix user/group that is not in 
sync between the NFS server and the client)

Thanks for the reply.

In this case the user _is_ authenticated.
keesb@client1:~$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: ke...@example.com

Valid starting ExpiresService principal
22-02-17 09:20:30  23-02-17 09:20:25  krbtgt/example@example.com

no, the user has a TGT.  a nfs/host.domain.tld@REALM ticket is needed to 
authenticate.

(( I'm trying to catch up on the acronyms. TGT. Reading wikipedia now. ))


What other grants could be needed? HBAC Rules?

Do I need an nfs principal for the client? (I didn't think so, but many HOWTO's 
say so [2]. Anyway, it
doesn't help to get access for the user.)

there are principals to create and keytabs to be updated on hte NFS sever, if 
not done already.

I did create a principal for the NFS server (using ipa service-add) and
add to the keytab on the NFS server (using ipa-getkeytab) ...
root@srv1# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
 --
 1 host/srv1.example@example.com (aes256-cts-hmac-sha1-96)
 1 host/srv1.example@example.com (aes128-cts-hmac-sha1-96)
 1 nfs/srv1.example@example.com (aes256-cts-hmac-sha1-96)
 1 nfs/srv1.example@example.com (aes128-cts-hmac-sha1-96)

Is this what you mean?

yes, if that is done, the server side components should be done for kerberos.  
have you set things up in /etc/idmapd.conf so your domain, REALM, etc are setup?

I don't think that a change of idmapd.conf (on the NFS server) is needed 
because all host
names are FQDN and everything is in one and the same REALM.
NFS needs to know how to map a user object to an ID and groups. 
identities established by kerberos do not directly translate to users.  
usually some sort of directory services are leveraged in order to 
accomplish this, though PAM and things like that can be used to.  by 
setting things in idmapd.conf, you are telling NFS who to translate 
kerberos identities into usernames, so ownership and permissions can be 
sync'd.



then the user should be able to pull the ticket for auth.

Sorry to ask, but how do I do that? On the client, I suppose, and by the user ??

keesb@client1$ kinit nfs/srv1.example@example.com
Password for nfs/srv1.example@example.com:

But I don't have a password for that. Hmm.

there is no need to init on the client side, as long as the TGT is obtained.  
you should never need to init the nfs/blah.. on the client side.

OK
So, it seems to me that all the basics are setup correctly. The mount succeeds. 
The user
has a TGT and still the (non-root) user cannot even stat the mount point, nor 
the directory
entry itself.

What puzzles me is that root can see everything, also without a TGT.
the mount will succeed, but the user does not have access because NFS 

Re: [Freeipa-users] Dogtag certs did not auto-renew, very stuck!

[Martin Basti]

On 23.02.2017 12:40, Peter Fern wrote:

On 23/02/17 20:27, Martin Basti wrote:

On 23.02.2017 10:21, Timo Aaltonen wrote:

And as you noticed, packaging nss-pem is not a trivial task because of
the way it uses private NSS api's that the libnss maintainer refuses to
make public.. OpenSSL, anyone? :P


We are working on it :) in future IPA may need only openssl

Doesn't this open the GPL/OpenSSL licensing can of worms (for distro !=
Fedora)?

IPA already requires OpenSSL so nothing should change.

--
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] Dogtag certs did not auto-renew, very stuck!

[Peter Fern]

On 23/02/17 20:27, Martin Basti wrote:
> On 23.02.2017 10:21, Timo Aaltonen wrote:
>> And as you noticed, packaging nss-pem is not a trivial task because of
>> the way it uses private NSS api's that the libnss maintainer refuses to
>> make public.. OpenSSL, anyone? :P
>>
> We are working on it :) in future IPA may need only openssl

Doesn't this open the GPL/OpenSSL licensing can of worms (for distro !=
Fedora)?

-- 
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] support for rfc2307AIX schema in IPA server

[Iulian Roman]

On Wed, Feb 22, 2017 at 9:02 PM, Michael Ströder 
wrote:

> Iulian Roman wrote:
> > On Wed, Feb 22, 2017 at 6:03 PM, Michael Ströder  > > wrote:
> >
> > Iulian Roman wrote:
> > > On Tue, Feb 21, 2017 at 4:31 PM, Rob Crittenden <
> rcrit...@redhat.com 
> > > >> wrote:
> > >
> > > Iulian Roman wrote:
> > > > Does anybody know if the rfc2307aix schema is supported in
> IPA server
> > >
> > > No, it isn't supported (it's the first I've ever heard of it).
> Looking
> > > at the schema I doubt it is something that would ever be fully
> supported.
> > >
> > > is there any possibility to extend the existing schema with
> additional
> > > attributes/object
> >
> > Do you really use this specific AIX schema?
> > If yes, which attributes for which purpose?
> >
> > I do need the aixAuxAccount and aixAuxGroup object classes . they
> implement some
> > password restrictions needed for security/compliance
>
> Password policy is something best enforced centrally in the authentication
> server and
> password management system. So IMHO this serves as perfect example for
> proprietary
> attributes you won't need.
>
> How is authentication done? SSH keys, Kerberos, LDAP simple bind?
>

Kerberos


> > +  some other security related attributes.
> > Personally i do not consider them a must - they are rather some nice to
> have features  -
> > but i have to migrate an environment which does use them. And i would
> like as well to
> > make the migration as transparent as possible (therefore without
> "missing features").
>
> Is the existing environment also an LDAP server with this particular AIX
> schema?
>

no, it is a custom/legacy  solution wich does not use LDAP but local
accounts which are centrally managed.

> Or are you trying to follow a migration path to LDAP suggested by IBM docs?
>
>
no, i've adapted some freeipa document which describes the client setup for
aix (in original form it does not work and it needed some modifications) ,
but i have to admit that the documentation for integrating unix clients is
poor and incomplete . IBM does recommend  TDS, which integrates seamlessly
with both AIX and Linux clients  + other features which should help in
integrating in heterogeneous environment,  but i am not evaluating that
solution currently (i may look into it only if i cannot integrate it with
IPA in the way i want).


> Being in your position I'd first compile a list of functional and security
> requirements
> and ask then whether these requirements can be implemented with FreeIPA.
> I'm curious to
> learn whether "some other security related attributes" are still needed
> after all.
>
> all the password restriction policies  (minage, maxage, number of
characters in the password, history of the old passwords, number of
characters, password dictionaries , etc) , loginretries - which "locks" the
account after a number of unsuccessful logins  , hostsallow/deny login ,
all the ulimit related parameters (that can probably be  ignored)  .  It is
not a matter if they increase the security or not or if they are really
needed, but a matter of complying to some security standards agreed between
two parties  . It would be easy to keep  them in the same format  than to
change the security standard  , tooling and processes behind (bureaucracy ,
overhead and complexity of the enterprise environment makes me try to avoid
that as much as possible , especially when there are many people and
departments involved , with their own mindset and playing different
politics).



Ciao, Michael.
>
>
-- 
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] Dogtag certs did not auto-renew, very stuck!

[Martin Basti]

On 23.02.2017 10:21, Timo Aaltonen wrote:

On 23.02.2017 02:04, Peter Fern wrote:

On 23/02/17 05:26, Rob Crittenden wrote:

It's been many moons since I worked on nss-pem but from what I can tell
it should be buildable outside of NSS so can ship as a separate package.
You might try building it locally to see if it resolves the issues for
you. It resides at https://github.com/kdudka/nss-pem

I had to modify an include path, and it links against some static libs
(libfreebl.a, libnssb.a, libnssckfw.a) that are not included in the
current Debian libnss3 packages, so a non-trivial packaging effort.  And
because certmonger appears to use nss directly, linking against a
different libcurl variant is also probably not an option.

There are other issues too - the default cert store path of
/etc/httpd/alias is still used in the deb package, however the correct
path is /etc/apache2/nssdb.

Good stuff, neatly hardcoded in src/dogtag.c. Thanks for pointing this
out, I'll get that fixed at least..

And as you noticed, packaging nss-pem is not a trivial task because of
the way it uses private NSS api's that the libnss maintainer refuses to
make public.. OpenSSL, anyone? :P


We are working on it :) in future IPA may need only openssl


--
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] Dogtag certs did not auto-renew, very stuck!

[Timo Aaltonen]

On 23.02.2017 02:04, Peter Fern wrote:
> On 23/02/17 05:26, Rob Crittenden wrote:
>> It's been many moons since I worked on nss-pem but from what I can tell
>> it should be buildable outside of NSS so can ship as a separate package.
>> You might try building it locally to see if it resolves the issues for
>> you. It resides at https://github.com/kdudka/nss-pem
> 
> I had to modify an include path, and it links against some static libs
> (libfreebl.a, libnssb.a, libnssckfw.a) that are not included in the
> current Debian libnss3 packages, so a non-trivial packaging effort.  And
> because certmonger appears to use nss directly, linking against a
> different libcurl variant is also probably not an option.
> 
> There are other issues too - the default cert store path of
> /etc/httpd/alias is still used in the deb package, however the correct
> path is /etc/apache2/nssdb.

Good stuff, neatly hardcoded in src/dogtag.c. Thanks for pointing this
out, I'll get that fixed at least..

And as you noticed, packaging nss-pem is not a trivial task because of
the way it uses private NSS api's that the libnss maintainer refuses to
make public.. OpenSSL, anyone? :P

-- 
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 Fedora 25 and IPA CentOS 7.3

[Ente Trompete]

Hi,

THX for your answer but as you can see in your test, you get freeipa-server 
4.4.3 installed and if you follow the link offered by Alexander Red Hat/CentOS 
uses another versioning as the FreeIPA project contained in Fedora. So to 
create a replica with freeipa-server 4.4.3 from a CentOS ipa-server 4.4.0- 
can work but must not. And with any patching of CentOS and/or Fedora new 
problems can appear.


I must either switch also the primary replica to FreeIPA (Fedora) or can’t use 
ARM based computer for the second. Maybe a Gigabyte BRIX is a got alternative. 
Of course really more expensive and the Banna PI was then bought for the trash, 
maybe I can install Android and use it as TV box ;-).


Br,
Silvio



Sent with [ProtonMail](https://protonmail.com) Secure Email.


 Original Message 
There is not any problem to install ipa-server on fedora.
There are provides.

sh# cat /etc/os-release
NAME=Fedora
...-- 
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] Recommended approach to VM snapshot prior to upgrade

[Martin Basti]

On 23.02.2017 00:47, Brian Mathis wrote:
I have a 3-node cluster running FreeIPA 4.2 on RHEL 7.2.  I would like 
to upgrade to RHEL 7.3 / IPA 4.4, and I want to make VM snapshots that 
I can rollback to in case there are issues.  What is the recommended 
approach to this?


Should services already be started when running the yum update?

It doesn't matter, updater will stop/start services as needed



Can I shut down each ipa service one by one, snapshot, then upgrade?  
How would replication be affected if I had to rollback to the older 
snapshot after other nodes had been upgraded?
You have to rollback all snapshots for the whole topology and then you 
can start IPA, otherwise replication conflicts may happen.

So I suggest to have snapshots of all servers before upgrade.


Or is it better to shut down all ipa services on all nodes, make 
snapshots, then perform the upgrade?  Obviously that would bring down 
the domain during the upgrade, but it would better ensure integrity.
This is the best for integrity, but in case there is no/low activity on 
servers, then one by one snapshots may work too.




Thanks,

~ Brian Mathis
@orev




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

Re: [Freeipa-users] FreeIPA 4.3.1 ipa-replica-install wrong exit code?

[Standa Laznicka]

On 02/23/2017 08:30 AM, Martin Basti wrote:


On 23.02.2017 00:17, Diogenes S. Jesus wrote:
We are ansible-playbooking FreeIPA and we don't want to care about if 
freeipa is installed, we just want to ignore errors if it already is 
- but for that the exit code is relevant.
Either the return code is wrong in the code or in the manual - 
according to the manual, it should be 3, but it's currently 1.



ubuntu@ipa02:~$ sudo -i
root@ipa02:~# http_proxy='' https_proxy='' ipa-replica-install 
--dirsrv-cert-file=/etc/ssl/private/ipa02.dev.pfx 
--http-cert-file=/etc/ssl/private/ipa02.dev.pfx --dirsrv-pin=export 
--http-pin=export
ipa.ipapython.install.cli.install_tool(Replica): ERROR  IPA server is 
already configured on this system.
If you want to reinstall the IPA server, please uninstall it first 
using 'ipa-server-install --uninstall'.
ipa.ipapython.install.cli.install_tool(Replica): ERROR  The 
ipa-replica-install command failed. See 
/var/log/ipareplica-install.log for more information


root@ipa02:~# echo $?
1

root@ipa02:~# cat /var/log/ipareplica-install.log
2017-02-22T22:49:45Z DEBUG Logging to /var/log/ipareplica-install.log
2017-02-22T22:49:45Z DEBUG ipa-replica-install was invoked with 
arguments [] and options: {'no_dns_sshfp': None, 'skip_schema_check': 
None, 'setup_kra': None, 'ip_addresses': None, 'mkhomedir': None, 
'no_pkinit': None, 'http_cert_files': 
['/etc/ssl/private/ipa02.dev.pfx'], 'no_ntp': None, 'verbose': False, 
'no_forwarders': None, 'keytab': None, 'ssh_trust_dns': None, 
'domain_name': None, 'http_cert_name': None, 'dirsrv_cert_files': 
['/etc/ssl/private/ipa02.dev.pfx'], 'no_dnssec_validation': None, 
'no_reverse': None, 'pkinit_cert_files': None, 'unattended': False, 
'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns': None, 
'no_sshd': None, 'no_ui_redirect': None, 'dirsrv_config_file': None, 
'forwarders': None, 'pkinit_cert_name': None, 'setup_ca': None, 
'realm_name': None, 'skip_conncheck': None, 'no_ssh': None, 
'dirsrv_cert_name': None, 'quiet': False, 'server': None, 
'setup_dns': None, 'host_name': None, 'log_file': None, 
'reverse_zones': None, 'allow_zone_overlap': None}

2017-02-22T22:49:45Z DEBUG IPA version 4.3.1
2017-02-22T22:49:45Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2017-02-22T22:49:45Z DEBUG Loading Index file from 
'/var/lib/ipa/sysrestore/sysrestore.index'

2017-02-22T22:49:45Z DEBUG httpd is configured
2017-02-22T22:49:45Z DEBUG kadmin is configured
2017-02-22T22:49:45Z DEBUG dirsrv is configured
2017-02-22T22:49:45Z DEBUG pki-tomcatd is not configured
2017-02-22T22:49:45Z DEBUG install is not configured
2017-02-22T22:49:45Z DEBUG krb5kdc is configured
2017-02-22T22:49:45Z DEBUG ntpd is configured
2017-02-22T22:49:45Z DEBUG named is not configured
2017-02-22T22:49:45Z DEBUG ipa_memcached is configured
2017-02-22T22:49:45Z DEBUG filestore has files
2017-02-22T22:49:45Z DEBUG   File 
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 171, 
in execute

return_value = self.run()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/cli.py", 
line 318, in run

cfgr.run()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 308, in run

self.validate()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 317, in validate

for nothing in self._validator():
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 372, in __runner

self._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 362, in __runner

step()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 359, in 

step = lambda: next(self.__gen)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", 
line 81, in run_generator_with_yield_from

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", 
line 59, in run_generator_with_yield_from

value = gen.send(prev_value)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 564, in _configure

next(validator)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 372, in __runner

self._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 449, in _handle_exception

self.__parent._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 446, in _handle_exception

super(ComponentBase, self)._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File 

Re: [Freeipa-users] authenticating with dns

[Martin Basti]

On 22.02.2017 23:26, Aaron Young wrote:

Hello Everyone

I recently lost the master master IPA server setup by the previous 
administrator.
As it stands now, if I try to add a new client, in order to standup a 
new replica, I get errors while trying to setup DNS. This led me to 
look at how authentication worked (I'm new to IPA) and I learned about 
the kerberos tools


I don't know if I'm familiar enough with the terminology to adequately 
describe what I'm experiencing, so I'll give you some of the commands 
and their results


but first, a bit on the design

before I got to this, we had

a <-> b <-> c <-> d

b was the master master

a, happened to point to two test servers nyc02ipa01 and nyc02ipa02 
(not pictured, I discovered them later when c and d started having 
problems)


a - nyc01ipa02
b - nyc01ipa01
c - ld4ipa01
d - ld4ipa02

currently, I have nyc02ipa02 <-> nyc01ipa02
the reason I have it limited like this is because all the other 
servers stopped replicating for one reason or another (mainly that 
they can't authenticate or in one case, there was a database record 
corruption)
Anyway, here are some activities and logs from the latest round of 
fixes and information activities I've been engaging in


22:54:32 root@nyc01ipa02:~# kinit admin
kinit: Clients credentials have been revoked while getting initial 
credentials


Reading through this 
 tells 
me that


# kadmin: modprinc -unlock PRINCNAME

will unlock an account...but if I can't get in

22:54:37 root@nyc01ipa02:~# kadmin
Authenticating as principal root/admin@MF with password.
kadmin: Client 'root/admin@MF' not found in Kerberos database
while initializing kadmin interface

on ld4ipa02, did a

# ipa-client-install --uninstall

then

# ipa-client-install --force-join --enable-dns-updates --permit -f
--ssh-trust-dns --request-cert --automount-location=LD4
--enable-dns-updates

DNS did not update, here is the relevant portion from 
/var/log/ipaclient-install.log


2017-02-20T18:46:49Z DEBUG Writing nsupdate commands to 
/etc/ipa/.dns_update.txt:
2017-02-20T18:46:49Z DEBUG debug

update delete ld4ipa02.mf. IN A
show
send

update delete ld4ipa02.mf. IN 
show
send

update add ld4ipa02.mf. 1200 IN A 10.102.100.140
show
send

2017-02-20T18:46:49Z DEBUG Starting external process
2017-02-20T18:46:49Z DEBUG args=/usr/bin/nsupdate -g 
/etc/ipa/.dns_update.txt
2017-02-20T18:46:49Z DEBUG Process finished, return code=1
2017-02-20T18:46:49Z DEBUG stdout=Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
ld4ipa02.mf. 0 ANY A

2017-02-20T18:46:49Z DEBUG stderr=Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34702
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ld4ipa02.mf. IN SOA

;; AUTHORITY SECTION:
mf. 1800 IN SOA ld4ipa01.mf. hostmaster.mf. 1487615509 3600 900 1209600 3600

Found zone name: mf
The master is: ld4ipa01.mf
start_gssrequest
tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor 
code may provide more information, Minor = Server DNS/ld4ipa01.mf@MF not found 
in Kerberos database.

2017-02-20T18:46:49Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g 
/etc/ipa/.dns_update.txt' returned non-zero exit status 1
2017-02-20T18:46:49Z ERROR Failed to update DNS records.
2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN A
2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN 
2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
2017-02-20T18:46:49Z DEBUG DNS resolver: Query:140.100.102.10.in-addr.arpa 
. IN PTR
2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
2017-02-20T18:46:49Z WARNING Missing A/ record(s) for host ld4ipa02.mf: 
10.102.100.140.
2017-02-20T18:46:49Z WARNING Missing reverse record(s) for address(es): 
10.102.100.140.

Why isn't there an entry for "DNS/ld4ipa01.mf@MF" in the Kerberos 
database?


klist -ktK /etc/dirsrv/ds.keytab on ld4ipa01 returns

Keytab name: FILE:/etc/dirsrv/ds.keytab

KVNO Timestamp Principal
 ---
--
2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF
(0x696a502bc73d209acdd36c42242f7f8aff9dbba1073b34ea018ed3bd9cdfd970)
2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF
(0xe031464b6948ea34f4291d40fca7a21e)
2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF
(0xe94a1c98fe79b6317901435d9e9e0257cefe438ff2ec527f)
2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF
(0x6aaf4c7fa6b51b9de032b7c6428307b5)
2 11/17/2016