[Freeipa-users] replication issues

[Lance Murray via FreeIPA-users]

We have 4 IPA servers setup in a circular replication (each server can
replicate to 2 other servers), which created a replication that looks like
an 'O' .. but we have some replication issues:

note: we are using freeIPA as DNS and Users authentication and
authorization.

1. some records do not seem to get replicated when they get updated to all
other nodes
2. almost weekly replication stops with many open files, ldapwhoami
processes, etc.
- replication-status.html usually will show Update Status = 'Error (1)
Can't acquire busy server'
- A restart of directory services sometimes fixes this, and sometimes a
server reboot is required
- no indication of failure in log files, other than 'can not contact
ldap server'
- sometimes restart of named-pkcs11 clears replication
- The Max CSN number on all nodes has a timestamp that is consistently
in the future. Which is very odd, and might be related.  Easy to
check by making a change on one of them, and then checking the CSN from the
config.

Our architecture is 2 data centers, with a pair of servers in each. For
reliability we want to make all servers available to each data center. We
are running on Centos 7.3.

It seems were are missing something somewhere to help make this reliable.
Errors 2-3 times a week is becoming a support nightmare.

Questions are:

1. should we have a different architecture (eg, 1 master, multiple slaves,
multi-master)?
2. should we replicate less frequently? (what is best practice)
3. currently known issues with replication on Centos 7.3?


Thanks,

-lance


-- 

*Lance Murray* | Senior Systems Admin | *SBI BITS*

Roppongi T-Cube 20F, 3-1-1 Roppongi, Minato-ku, Tokyo 106-0032 Japan

*T* +81-3-4510-7000 | *M* +81-070-1529-1960 | *E*
lance.mur...@sbibits.com


-- 
*This correspondence (including any attachments) is for the intended 
recipient(s) only. It may contain confidential or privileged information or 
both. No confidentiality or privilege is waived or lost by any 
mis-transmission. If you receive this correspondence by mistake, please 
contact the sender immediately, delete this correspondence (and all 
attachments) and destroy any hard copies. You must not use, disclose, copy, 
distribute or rely on any part of this correspondence (including any 
attachments) if you are not the intended 
recipient(s).本メッセージに記載および添付されている情報（以下、総称して「本情報」といいます。）は、本来の受信者による使用のみを意図しています。誤送信等により本情報を取得された場合でも、本情報に係る秘密、または法律上の秘匿特権が失われるものではありません。本電子メールを受取られた方が、本来の受信者ではない場合には、本情報及びそのコピーすべてを削除・破棄し、本電子メールが誤って届いた旨を発信者宛てにご通知下さいますようお願いします。本情報の閲覧、発信または本情報に基づくいかなる行為も明確に禁止されていることをご了承ください。*
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Alexandre Pitre via FreeIPA-users]

Although, the explanation from Alexander Bokovoy made perfect sense, I'm
still facing the issue after I re-established the AD trust successfully:

(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_cli_auth_step]
(0x1000): the connection will expire at 1502764720
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
(0x0100): Executing sasl bind mech: GSSAPI, user: host/centos.domain.ad.com
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
(0x0020): ldap_sasl_bind failed (-2)[Local error]
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
(0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure.  Minor code may provide more information
(Server krbtgt/ad@tenant.ad.com not found in Kerberos database)]
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [child_sig_handler]
(0x1000): Waiting for child [5197].
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [child_sig_handler]
(0x0100): child [5197] finished successfully.
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[sdap_cli_connect_recv] (0x0040): Unable to establish connection
[1432158225]: Authentication Failed
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called
from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv:
2048
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status]
(0x0100): Marking port 0 of server 'ipaserver02.ipa.ad.com' as 'not working'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status]
(0x0400): Marking port 0 of duplicate server 'ipaserver02.ipa.ad.com' as
'not working'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_handle_release]
(0x2000): Trace: sh[0x7f4811278710], connected[1], ops[(nil)],
ldap[0x7f481121f780], destructor_lock[0], release_memory[0]
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[remove_connection_callback] (0x4000): Successfully removed connection
callback.
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[sdap_id_op_connect_done] (0x4000): attempting failover retry on op #1
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[sdap_id_op_connect_step] (0x4000): beginning to connect
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_port_status]
(0x1000): Port status of port 0 for server '(no name)' is 'neutral'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6
seconds
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolve_srv_send]
(0x0200): The status of SRV lookup is neutral
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[resolv_discover_srv_next_domain] (0x0400): SRV resolution of service
'ldap'. Will use DNS discovery domain 'domain.ad.com'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolv_getsrv_send]
(0x0100): Trying to resolve SRV record of '_ldap._tcp.domain.ad.com'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[sdap_id_release_conn_data] (0x4000): releasing unused connection
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[request_watch_destructor] (0x0400): Deleting request watch
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[resolv_discover_srv_done] (0x0040): SRV query failed [4]: Domain name not
found
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status]
(0x0100): Marking port 0 of server '(no name)' as 'not working'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolve_srv_done]
(0x0040): Unable to resolve SRV [1432158235]: SRV record not found
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [set_srv_data_status]
(0x0100): Marking SRV lookup of service 'IPA' as 'not resolved'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup
meta-server), resolver returned [1432158235]: SRV record not found
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[be_resolve_server_process] (0x1000): Trying with the next one!
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_server_status]
(0x1000): Status of server 'ipaserver01.ipa.ad.com' is 'name resolved'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_port_status]
(0x1000): Port status of port 0 for server 'ipaserver01.ipa.ad.com' is 'not

[Freeipa-users] Re: HTTPD does not start when NSS enabled

[Julian Gethmann via FreeIPA-users]

On 08/14/2017 09:51 PM, Rob Crittenden wrote:

Julian Gethmann wrote:

On 08/14/2017 05:46 PM, Rob Crittenden wrote:

Julian Gethmann wrote:

Hallo,

On 08/14/2017 04:21 PM, Rob Crittenden wrote:

Julian Gethmann via FreeIPA-users wrote:

Hallo,

Unfortunately I don't know when this problem occurred first, but it
may
have occurred after an update.
The httpd does not start and aborts with the error

[:info] [pid 15383] Using nickname Server-Cert.
[...] [:error] [pid 15383] Certificate not found: 'Server-Cert'

when I want to start FreeIPA via "systemctl start ipa" or "ipactl
start"
or "systemctl start httpd"
If I turn the NSSEngine off it starts of cause.

In contrast to this message "ipa-getcert list -d /etc/httpd/alias/ -n
Server-Cert" does find a certificate, if I get the output [1] right.


ipa-getcert shows certs that are tracked by certmonger but doesn't
guarantee that those certificates actually exist in the filesystem
(they
did at the time tracking was started).

You need to look at the Apache NSS database:

# certutil -L -d /etc/httpd/alias

Ok, I also did this, but it seems to be there
# certutil -L -d /etc/httpd/alias

Certificate Nickname Trust
Attributes

SSL,S/MIME,JAR/XPI

Signing-Cert u,u,u
ipaCert  u,u,u
Server-Cert  Pu,u,u
EXAMPLE.COM IPA CA   CT,C,C



I'd check FS permissions. /etc/httpd/alias/*.db should be root:apache
0640

ok, the db were "root:apache 0660", but they were readable at least and
making them 0640 did not help either.


If that checks out, look for SELinux issues by starting httpd then
running: ausearch -m AVC -ts recent

I disabled SELinux for testing it, but that did not work. Now I also
tested:
# ausearch -m AVC -ts recent




As a last resort perhaps the NSS database is corrupted. You can exercise
it with:

# certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f
/etc/httpd/alias/pwdfile.txt

You should get: certutil: certificate is valid


I do get it:
# certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f
/etc/httpd/alias/pwdfile.txt
certutil: certificate is valid


If I just want to start httpd and not via IPA or with --force I get a
different error, which I think might be because the services started
before httpd in the IPA start-up-phase aren't running since the start of
IPA aborted:

-- Unit httpd.service has begun starting up.
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: ipa
  : ERRORUnknown error while retrieving setting from ldap
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:
Traceback (most recent call last):
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File
"/usr/libexec/ipa/ipa-httpd-kdcproxy", line 84, in _ldap_con
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:
self.con.do_bind(timeout=self.time_limit)
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 16
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:
self.do_external_bind(pw_name, timeout=timeout)
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 16
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:
self.__bind_with_wait(self.external_bind, timeout, user_name)
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 16
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:
self.__wait_for_connection(timeout)
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 16
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:
wait_for_open_socket(lurl.hostport, timeout)
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File
"/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 13
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: raise e
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: error:
[Errno 111] Connection refused
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: ipa
  : ERRORUnknown error while retrieving setting from ldap
Aug 14 19:05:14 ipa_server.example.com systemd[1]: httpd.service:
Control process exited, code=exited status=1
Aug 14 19:05:14 ipa_server.example.com audit[1]: SERVICE_START pid=1
uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s
Aug 14 19:05:14 ipa_server.example.com systemd[1]: Failed to start The
Apache HTTP Server.



The KDC proxy needs to talk to LDAP. If you want to continue down this
road you can edit /etc/systemd/system/httpd.service.d/ipa.conf and
comment out the ExecStartPre 

[Freeipa-users] Re: IPA Master won't start and replicas are not taking over

[Rob Crittenden via FreeIPA-users]

Randy Morgan wrote:
> After some serious arm twisting, I was finally able to get the server to
> run a yum update.  It would appear that some of the files for ipa had
> become corrupted and this was the reason it would not start.  After the
> yum update, it started just fine and I was able to run an IPA-upgrade
> command.  That seemed to correct the problem with the server being
> down.  No I will have to work through the multiple master configs and
> make sure everything is working like it is supposed to so this does not
> happen again.

Ok, glad it's working again.

Still the lack of failover wasn't good. It may be the way your clients
are configured.

rob

> 
> Randy
> 
> Randy Morgan
> CSR
> Department of Chemistry and Biochemistry
> Brigham Young University
> 801-422-4100
> 
> On 08/14/2017 12:58, Rob Crittenden wrote:
>> Randy Morgan via FreeIPA-users wrote:
>>> Over the weekend our IPA Master failed and I can not get ipactl to
>>> start, the Directory Service fails.  We have two replicas and I was
>>> under the impression that if one of the servers failed the others would
>>> pickup the load, that is not happening however, and we have been down
>>> for two days now.  Is there something that I need to do to the replicas
>>> to make one of them the new master, and if so could you walk me through
>>> the conversion?
>> Failover depends on your configuration and what isn't failing over. Can
>> you provide more details on what isn't working? Be sure to include
>> detrails on how your clients are configured, whether your IPA servers
>> have DNS srv records, etc.
>>
>> Once we get that working we can tackle what is going on with the failed
>> master.
>>
>> rob
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Fedora 26 upgrade, mkhomedir stops working

[Jakub Hrozek via FreeIPA-users]

On Mon, Aug 14, 2017 at 11:05:23AM -0400, Steve Weeks via FreeIPA-users wrote:
> This is what I get in sssd_pam.log:
> 
> [pam_dp_process_reply] (0x0200): received: [6 (Permission denied)][
> ad.example.com]
> [pam_reply] (0x0200): pam_reply called with result [6]: Permission denied.
> 
> I don't think the bug you listed applies.  We have the service set to 'any'
> and hbactest says the user should be able to login.
> 
> Any idea what to try next or what logs to look at?

I think the sssd domain logs are the next best place to look, becase
there you'd see the rules sssd evaluates along with their input.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: HTTPD does not start when NSS enabled

[Julian Gethmann via FreeIPA-users]

On 08/14/2017 05:46 PM, Rob Crittenden wrote:

Julian Gethmann wrote:

Hallo,

On 08/14/2017 04:21 PM, Rob Crittenden wrote:

Julian Gethmann via FreeIPA-users wrote:

Hallo,

Unfortunately I don't know when this problem occurred first, but it may
have occurred after an update.
The httpd does not start and aborts with the error

[:info] [pid 15383] Using nickname Server-Cert.
[...] [:error] [pid 15383] Certificate not found: 'Server-Cert'

when I want to start FreeIPA via "systemctl start ipa" or "ipactl start"
or "systemctl start httpd"
If I turn the NSSEngine off it starts of cause.

In contrast to this message "ipa-getcert list -d /etc/httpd/alias/ -n
Server-Cert" does find a certificate, if I get the output [1] right.


ipa-getcert shows certs that are tracked by certmonger but doesn't
guarantee that those certificates actually exist in the filesystem (they
did at the time tracking was started).

You need to look at the Apache NSS database:

# certutil -L -d /etc/httpd/alias

Ok, I also did this, but it seems to be there
# certutil -L -d /etc/httpd/alias

Certificate Nickname Trust
Attributes

SSL,S/MIME,JAR/XPI

Signing-Cert u,u,u
ipaCert  u,u,u
Server-Cert  Pu,u,u
EXAMPLE.COM IPA CA   CT,C,C



I'd check FS permissions. /etc/httpd/alias/*.db should be root:apache 0640
ok, the db were "root:apache 0660", but they were readable at least and 
making them 0640 did not help either.


If that checks out, look for SELinux issues by starting httpd then
running: ausearch -m AVC -ts recent

I disabled SELinux for testing it, but that did not work. Now I also tested:
# ausearch -m AVC -ts recent




As a last resort perhaps the NSS database is corrupted. You can exercise
it with:

# certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f
/etc/httpd/alias/pwdfile.txt

You should get: certutil: certificate is valid


I do get it:
# certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f 
/etc/httpd/alias/pwdfile.txt

certutil: certificate is valid

rob




If I just want to start httpd and not via IPA or with --force I get a 
different error, which I think might be because the services started 
before httpd in the IPA start-up-phase aren't running since the start of 
IPA aborted:


-- Unit httpd.service has begun starting up.
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: ipa 
 : ERRORUnknown error while retrieving setting from ldap
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: 
Traceback (most recent call last):
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File 
"/usr/libexec/ipa/ipa-httpd-kdcproxy", line 84, in _ldap_con
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: 
self.con.do_bind(timeout=self.time_limit)
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File 
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 16
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: 
self.do_external_bind(pw_name, timeout=timeout)
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File 
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 16
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: 
self.__bind_with_wait(self.external_bind, timeout, user_name)
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File 
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 16
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: 
self.__wait_for_connection(timeout)
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File 
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 16
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: 
wait_for_open_socket(lurl.hostport, timeout)
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]:   File 
"/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 13
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: 
raise e
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: error: 
[Errno 111] Connection refused
Aug 14 19:05:14 ipa_server.example.com ipa-httpd-kdcproxy[22551]: ipa 
 : ERRORUnknown error while retrieving setting from ldap
Aug 14 19:05:14 ipa_server.example.com systemd[1]: httpd.service: 
Control process exited, code=exited status=1
Aug 14 19:05:14 ipa_server.example.com audit[1]: SERVICE_START pid=1 
uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s
Aug 14 19:05:14 ipa_server.example.com systemd[1]: Failed to start The 
Apache HTTP Server.

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: IPA Master won't start and replicas are not taking over

[Felipe Barreto Volpone via FreeIPA-users]

Randy,

Actually, there is not much difference between a replica and a master (in
general),
you can check more details in this blog post from rcrit:
https://blog-rcritten.rhcloud.com/?p=67

About Dir. Server failing, could you share the logs?
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Configuring_Logs.html


On Mon, Aug 14, 2017 at 2:04 PM, Randy Morgan via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Over the weekend our IPA Master failed and I can not get ipactl to start,
> the Directory Service fails.  We have two replicas and I was under the
> impression that if one of the servers failed the others would pickup the
> load, that is not happening however, and we have been down for two days
> now.  Is there something that I need to do to the replicas to make one of
> them the new master, and if so could you walk me through the conversion?
>
> Thanks,
>
> Randy
>
> --
> Randy Morgan
> CSR
> Department of Chemistry and Biochemistry
> Brigham Young University
> 801-422-4100
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Ubuntu 16 Desktop trouble with AD credentials

[Alexander Bokovoy via FreeIPA-users]

On ma, 14 elo 2017, Steve Weeks wrote:

It is example.com and ad.example.com, but all DNS is handled by an external
server so I assumed neither was a subdomain.  I don't understand DNS much
and it seems to work just fine with Fedora 25 ipa clients and ad users.

Which DNS server handles DNS zones is irrelevant. It is not about DNS
zones, it is an issue with how Active Directory treats own domains (AD
domain != DNS domain). You can check
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/76P2HI7JYH6QXAQGAEEF5G7KFHMVO3E7/
for more details.

However, your specific arrangement of example.com for IPA and
ad.example.com for AD is known to not work, as I said earlier.




On Mon, Aug 14, 2017 at 1:36 PM, Alexander Bokovoy 
wrote:


On ma, 14 elo 2017, Steve Weeks wrote:


No, the IPA and AD domains are separate, but do have a cross-trust.

We are running IPA 4.4.  This all works fine on Fedora 25 systems.


Can you be more specific? In your logs below you choose ad.example.com
and example.com. This is known to not work. If this is not your
configuration then why did you choose it to obfuscate? Details matter.





On Mon, Aug 14, 2017 at 12:14 PM, Alexander Bokovoy 
wrote:

On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:


I'm having trouble logging in via the gui console to an Ubuntu 16 Desktop

host that is affiliated with a FreeIPA server, which in turn is
affiliated
with an Active Directory server.

When I try to log in with debugging turned up on the SSSD I see an
underlying error in the krb5_child log file: Cannot find KDC for realm "
EXAMPLE.COM" while getting credentials for host/
myhost.example@example.com

Following an example from the freeipa-users mailing list, I am just
working
with kinit and kvno to identify the underlying problem. I get the same
error, which I suppose is good. But I don't know how to resolve it from
here. The transcript is below. On the first try at kvno, I get the same
error. On the second try, it works. Any idea why? I suspect the failure
on
the first try is the real problem with authentication from the console.

Any hints what to try next?

Do you really have AD as a subdomain of IPA?


I suspect you hit https://bugzilla.redhat.com/show_bug.cgi?id=1421869
There is no currently resolution for this. If you'd use different
domain trees (example.com v example.org) it would work. It would work
also for AD owning example.com and IPA being in ipa.example.com.


Thanks


- /etc/krb5.conf -
#File modified by ipa-client-install

includedir */var/lib/sss/pubconf/krb5.include.d/*


[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}


[realms]
 EXAMPLE.COM = {
   pkinit_anchors = FILE:/etc/ipa/ca.crt

 }


[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM



- Transcript -


$ kdestroy -A


$ kinit adu...@ad.example.com
Password for adu...@ad.example.com:


$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: adu...@ad.example.com

Valid starting   Expires  Service principal
08/14/2017 09:59:22  08/14/2017 19:59:22  krbtgt/AD.EXAMPLE.COM@AD.EXAMP
LE.COM
renew until 08/15/2017 09:59:17


$ KRB5_TRACE=/dev/stdout kvno host/myhost.example@example.com
[1994] 1502719211.714019: Getting credentials adu...@ad.example.com ->
host/myhost.example@example.com using ccache
KEYRING:persistent:1000:1000
[1994] 1502719211.714237: Retrieving adu...@ad.example.com ->
host/myhost.example@example.com from KEYRING:persistent:1000:1000
with result: -1765328243/Matching credential not found
[1994] 1502719211.714318: Retrieving adu...@ad.example.com ->
krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
result: -1765328243/Matching credential not found
[1994] 1502719211.714376: Retrieving adu...@ad.example.com ->
krbtgt/ad.example@ad.example.com from KEYRING:persistent:1000:1000
with result: 0/Success
[1994] 1502719211.714395: Starting with TGT for client realm:
adu...@ad.example.com -> krbtgt/ad.example@ad.example.com
[1994] 1502719211.714439: Retrieving adu...@ad.example.com ->
krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
result: -1765328243/Matching credential not found
[1994] 1502719211.714456: Requesting TGT
krbtgt/example@ad.example.com using TGT
krbtgt/ad.example@ad.example.com
[1994] 1502719211.714486: Generated subkey for TGS request:
aes256-cts/020C
[1994] 1502719211.714525: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[1994] 1502719211.714605: Encoding request body and padata into FAST
request
[1994] 1502719211.714662: Sending request (1686 bytes) to
AD.EXAMPLE.COM
[1994] 1502719211.717532: Resolving hostname 

[Freeipa-users] Re: Ubuntu 16 Desktop trouble with AD credentials

[Steve Weeks via FreeIPA-users]

It is example.com and ad.example.com, but all DNS is handled by an external
server so I assumed neither was a subdomain.  I don't understand DNS much
and it seems to work just fine with Fedora 25 ipa clients and ad users.

On Mon, Aug 14, 2017 at 1:36 PM, Alexander Bokovoy 
wrote:

> On ma, 14 elo 2017, Steve Weeks wrote:
>
>> No, the IPA and AD domains are separate, but do have a cross-trust.
>>
>> We are running IPA 4.4.  This all works fine on Fedora 25 systems.
>>
> Can you be more specific? In your logs below you choose ad.example.com
> and example.com. This is known to not work. If this is not your
> configuration then why did you choose it to obfuscate? Details matter.
>
>
>
>
>> On Mon, Aug 14, 2017 at 12:14 PM, Alexander Bokovoy 
>> wrote:
>>
>> On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:
>>>
>>> I'm having trouble logging in via the gui console to an Ubuntu 16 Desktop
 host that is affiliated with a FreeIPA server, which in turn is
 affiliated
 with an Active Directory server.

 When I try to log in with debugging turned up on the SSSD I see an
 underlying error in the krb5_child log file: Cannot find KDC for realm "
 EXAMPLE.COM" while getting credentials for host/
 myhost.example@example.com

 Following an example from the freeipa-users mailing list, I am just
 working
 with kinit and kvno to identify the underlying problem. I get the same
 error, which I suppose is good. But I don't know how to resolve it from
 here. The transcript is below. On the first try at kvno, I get the same
 error. On the second try, it works. Any idea why? I suspect the failure
 on
 the first try is the real problem with authentication from the console.

 Any hints what to try next?

 Do you really have AD as a subdomain of IPA?
>>>
>>> I suspect you hit https://bugzilla.redhat.com/show_bug.cgi?id=1421869
>>> There is no currently resolution for this. If you'd use different
>>> domain trees (example.com v example.org) it would work. It would work
>>> also for AD owning example.com and IPA being in ipa.example.com.
>>>
>>>
>>> Thanks

 - /etc/krb5.conf -
 #File modified by ipa-client-install

 includedir */var/lib/sss/pubconf/krb5.include.d/*


 [libdefaults]
  default_realm = EXAMPLE.COM
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}


 [realms]
  EXAMPLE.COM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }


 [domain_realm]
  .example.com = EXAMPLE.COM
  example.com = EXAMPLE.COM



 - Transcript -


 $ kdestroy -A


 $ kinit adu...@ad.example.com
 Password for adu...@ad.example.com:


 $ klist
 Ticket cache: KEYRING:persistent:1000:1000
 Default principal: adu...@ad.example.com

 Valid starting   Expires  Service principal
 08/14/2017 09:59:22  08/14/2017 19:59:22  krbtgt/AD.EXAMPLE.COM@AD.EXAMP
 LE.COM
 renew until 08/15/2017 09:59:17


 $ KRB5_TRACE=/dev/stdout kvno host/myhost.example@example.com
 [1994] 1502719211.714019: Getting credentials adu...@ad.example.com ->
 host/myhost.example@example.com using ccache
 KEYRING:persistent:1000:1000
 [1994] 1502719211.714237: Retrieving adu...@ad.example.com ->
 host/myhost.example@example.com from KEYRING:persistent:1000:1000
 with result: -1765328243/Matching credential not found
 [1994] 1502719211.714318: Retrieving adu...@ad.example.com ->
 krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
 result: -1765328243/Matching credential not found
 [1994] 1502719211.714376: Retrieving adu...@ad.example.com ->
 krbtgt/ad.example@ad.example.com from KEYRING:persistent:1000:1000
 with result: 0/Success
 [1994] 1502719211.714395: Starting with TGT for client realm:
 adu...@ad.example.com -> krbtgt/ad.example@ad.example.com
 [1994] 1502719211.714439: Retrieving adu...@ad.example.com ->
 krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
 result: -1765328243/Matching credential not found
 [1994] 1502719211.714456: Requesting TGT
 krbtgt/example@ad.example.com using TGT
 krbtgt/ad.example@ad.example.com
 [1994] 1502719211.714486: Generated subkey for TGS request:
 aes256-cts/020C
 [1994] 1502719211.714525: etypes requested in TGS request: aes256-cts,
 aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
 [1994] 1502719211.714605: Encoding request body and padata into FAST
 request
 [1994] 1502719211.714662: Sending request (1686 bytes) to
 AD.EXAMPLE.COM
 [1994] 

[Freeipa-users] Re: Ubuntu 16 Desktop trouble with AD credentials

[Alexander Bokovoy via FreeIPA-users]

On ma, 14 elo 2017, Steve Weeks wrote:

No, the IPA and AD domains are separate, but do have a cross-trust.

We are running IPA 4.4.  This all works fine on Fedora 25 systems.

Can you be more specific? In your logs below you choose ad.example.com
and example.com. This is known to not work. If this is not your
configuration then why did you choose it to obfuscate? Details matter.




On Mon, Aug 14, 2017 at 12:14 PM, Alexander Bokovoy 
wrote:


On ma, 14 elo 2017, Steve Weeks via FreeIPA-users wrote:


I'm having trouble logging in via the gui console to an Ubuntu 16 Desktop
host that is affiliated with a FreeIPA server, which in turn is affiliated
with an Active Directory server.

When I try to log in with debugging turned up on the SSSD I see an
underlying error in the krb5_child log file: Cannot find KDC for realm "
EXAMPLE.COM" while getting credentials for host/
myhost.example@example.com

Following an example from the freeipa-users mailing list, I am just
working
with kinit and kvno to identify the underlying problem. I get the same
error, which I suppose is good. But I don't know how to resolve it from
here. The transcript is below. On the first try at kvno, I get the same
error. On the second try, it works. Any idea why? I suspect the failure on
the first try is the real problem with authentication from the console.

Any hints what to try next?


Do you really have AD as a subdomain of IPA?

I suspect you hit https://bugzilla.redhat.com/show_bug.cgi?id=1421869
There is no currently resolution for this. If you'd use different
domain trees (example.com v example.org) it would work. It would work
also for AD owning example.com and IPA being in ipa.example.com.



Thanks

- /etc/krb5.conf -
#File modified by ipa-client-install

includedir */var/lib/sss/pubconf/krb5.include.d/*


[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}


[realms]
 EXAMPLE.COM = {
   pkinit_anchors = FILE:/etc/ipa/ca.crt

 }


[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM



- Transcript -


$ kdestroy -A


$ kinit adu...@ad.example.com
Password for adu...@ad.example.com:


$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: adu...@ad.example.com

Valid starting   Expires  Service principal
08/14/2017 09:59:22  08/14/2017 19:59:22  krbtgt/AD.EXAMPLE.COM@AD.EXAMP
LE.COM
renew until 08/15/2017 09:59:17


$ KRB5_TRACE=/dev/stdout kvno host/myhost.example@example.com
[1994] 1502719211.714019: Getting credentials adu...@ad.example.com ->
host/myhost.example@example.com using ccache
KEYRING:persistent:1000:1000
[1994] 1502719211.714237: Retrieving adu...@ad.example.com ->
host/myhost.example@example.com from KEYRING:persistent:1000:1000
with result: -1765328243/Matching credential not found
[1994] 1502719211.714318: Retrieving adu...@ad.example.com ->
krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
result: -1765328243/Matching credential not found
[1994] 1502719211.714376: Retrieving adu...@ad.example.com ->
krbtgt/ad.example@ad.example.com from KEYRING:persistent:1000:1000
with result: 0/Success
[1994] 1502719211.714395: Starting with TGT for client realm:
adu...@ad.example.com -> krbtgt/ad.example@ad.example.com
[1994] 1502719211.714439: Retrieving adu...@ad.example.com ->
krbtgt/example@example.com from KEYRING:persistent:1000:1000 with
result: -1765328243/Matching credential not found
[1994] 1502719211.714456: Requesting TGT
krbtgt/example@ad.example.com using TGT
krbtgt/ad.example@ad.example.com
[1994] 1502719211.714486: Generated subkey for TGS request:
aes256-cts/020C
[1994] 1502719211.714525: etypes requested in TGS request: aes256-cts,
aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
[1994] 1502719211.714605: Encoding request body and padata into FAST
request
[1994] 1502719211.714662: Sending request (1686 bytes) to AD.EXAMPLE.COM
[1994] 1502719211.717532: Resolving hostname ad-host.ad.example.com.
[1994] 1502719211.719053: Sending initial UDP request to dgram
192.168.1.2:88
[1994] 1502719211.742171: Received answer (309 bytes) from dgram
192.168.1.2:88
[1994] 1502719211.743066: Response was not from master KDC
[1994] 1502719211.743082: Decoding FAST response
[1994] 1502719211.743109: Request or response is too big for UDP;
retrying with TCP
[1994] 1502719211.743113: Sending request (1686 bytes) to
AD.EXAMPLE.COM (tcp only)
[1994] 1502719211.743971: Resolving hostname ad-host.ad.example.com.
[1994] 1502719211.744908: Initiating TCP connection to stream
192.168.1.2:88
[1994] 1502719211.764062: Sending TCP request to stream 192.168.1.2:88
[1994] 1502719211.805666: Received answer (1643 bytes) from stream
192.168.1.2:88
[1994] 1502719211.805678: Terminating TCP connection to 

[Freeipa-users] IPA Master won't start and replicas are not taking over

[Randy Morgan via FreeIPA-users]

Over the weekend our IPA Master failed and I can not get ipactl to 
start, the Directory Service fails.  We have two replicas and I was 
under the impression that if one of the servers failed the others would 
pickup the load, that is not happening however, and we have been down 
for two days now.  Is there something that I need to do to the replicas 
to make one of them the new master, and if so could you walk me through 
the conversion?


Thanks,

Randy

--
Randy Morgan
CSR
Department of Chemistry and Biochemistry
Brigham Young University
801-422-4100
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] using freeipa with an AWS elastic load balancer

[ridha.zorgui--- via FreeIPA-users]

I set up a FreeIPA master and replica behind an elastic load balancer in AWS 
cloud. FreeIPA Clients will be contacting the replica and the master sever 
through the load balancer so the dns name used when configurting the clients is 
the ELB CNAME. The problem is when retreiving ldap data and during the 
authentication, the SSL handshake fails as the certificate sent back from the 
master or replica has a hostname different than the one used in the sssd ( the 
ELB CNAME). so the connection is terminated.  There is a workaround which is 
the use reqcert=allow but this bring a security issue with a MITM attack. 
another solution i found is the use SAN. I was able to add the ELB DNS as a SAN 
in freeipa servers certificate. i made sure it is there by downloading the 
certificate and checking that the elb san exist but when testing it the same 
problem remain. Please help.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: HTTPD does not start when NSS enabled

[Rob Crittenden via FreeIPA-users]

Julian Gethmann wrote:
> Hallo,
> 
> On 08/14/2017 04:21 PM, Rob Crittenden wrote:
>> Julian Gethmann via FreeIPA-users wrote:
>>> Hallo,
>>>
>>> Unfortunately I don't know when this problem occurred first, but it may
>>> have occurred after an update.
>>> The httpd does not start and aborts with the error
>>>
>>> [:info] [pid 15383] Using nickname Server-Cert.
>>> [...] [:error] [pid 15383] Certificate not found: 'Server-Cert'
>>>
>>> when I want to start FreeIPA via "systemctl start ipa" or "ipactl start"
>>> or "systemctl start httpd"
>>> If I turn the NSSEngine off it starts of cause.
>>>
>>> In contrast to this message "ipa-getcert list -d /etc/httpd/alias/ -n
>>> Server-Cert" does find a certificate, if I get the output [1] right.
>>
>> ipa-getcert shows certs that are tracked by certmonger but doesn't
>> guarantee that those certificates actually exist in the filesystem (they
>> did at the time tracking was started).
>>
>> You need to look at the Apache NSS database:
>>
>> # certutil -L -d /etc/httpd/alias
> Ok, I also did this, but it seems to be there
> # certutil -L -d /etc/httpd/alias
> 
> Certificate Nickname Trust
> Attributes
> 
> SSL,S/MIME,JAR/XPI
> 
> Signing-Cert u,u,u
> ipaCert  u,u,u
> Server-Cert  Pu,u,u
> EXAMPLE.COM IPA CA   CT,C,C


I'd check FS permissions. /etc/httpd/alias/*.db should be root:apache 0640

If that checks out, look for SELinux issues by starting httpd then
running: ausearch -m AVC -ts recent

As a last resort perhaps the NSS database is corrupted. You can exercise
it with:

# certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f
/etc/httpd/alias/pwdfile.txt

You should get: certutil: certificate is valid

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Fedora 26 upgrade, mkhomedir stops working

[Steve Weeks via FreeIPA-users]

This is what I get in sssd_pam.log:

[pam_dp_process_reply] (0x0200): received: [6 (Permission denied)][
ad.example.com]
[pam_reply] (0x0200): pam_reply called with result [6]: Permission denied.

I don't think the bug you listed applies.  We have the service set to 'any'
and hbactest says the user should be able to login.

Any idea what to try next or what logs to look at?


On Sat, Aug 12, 2017 at 7:37 AM, Lukas Slebodnik 
wrote:

> On (11/08/17 14:17), Steve Weeks via FreeIPA-users wrote:
> >We are running FreeIPA 4.4
> >
> >I just upgraded a system from fedora 25 to fedora 26 using dnf.
> >
> >The first problem is that the mkhomedir option is lost.  I've reinstated
> it
> >with:
> >
> >authconfig --enablemkhomedir --update
> >
> >The second problem is that AD users still can't login.  This is a server
> >system with a tty style login.  The response from login is "Login
> >incorrect".  When I look in the logs, I see "Permission denied".  hbactest
> >says that the users should have access.
> >
> Which pam service was denied?
>
> @see also https://bugzilla.redhat.com/show_bug.cgi?id=1474899#c8
>
> LS
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: HTTPD does not start when NSS enabled

[Julian Gethmann via FreeIPA-users]

Hallo,

On 08/14/2017 04:21 PM, Rob Crittenden wrote:

Julian Gethmann via FreeIPA-users wrote:

Hallo,

Unfortunately I don't know when this problem occurred first, but it may
have occurred after an update.
The httpd does not start and aborts with the error

[:info] [pid 15383] Using nickname Server-Cert.
[...] [:error] [pid 15383] Certificate not found: 'Server-Cert'

when I want to start FreeIPA via "systemctl start ipa" or "ipactl start"
or "systemctl start httpd"
If I turn the NSSEngine off it starts of cause.

In contrast to this message "ipa-getcert list -d /etc/httpd/alias/ -n
Server-Cert" does find a certificate, if I get the output [1] right.


ipa-getcert shows certs that are tracked by certmonger but doesn't
guarantee that those certificates actually exist in the filesystem (they
did at the time tracking was started).

You need to look at the Apache NSS database:

# certutil -L -d /etc/httpd/alias

Ok, I also did this, but it seems to be there
# certutil -L -d /etc/httpd/alias

Certificate Nickname Trust 
Attributes


SSL,S/MIME,JAR/XPI

Signing-Cert u,u,u
ipaCert  u,u,u
Server-Cert  Pu,u,u
EXAMPLE.COM IPA CA   CT,C,C

Thanks,
Julian


rob


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: HTTPD does not start when NSS enabled

[Rob Crittenden via FreeIPA-users]

Julian Gethmann via FreeIPA-users wrote:
> Hallo,
> 
> Unfortunately I don't know when this problem occurred first, but it may
> have occurred after an update.
> The httpd does not start and aborts with the error
> 
> [:info] [pid 15383] Using nickname Server-Cert.
> [...] [:error] [pid 15383] Certificate not found: 'Server-Cert'
> 
> when I want to start FreeIPA via "systemctl start ipa" or "ipactl start"
> or "systemctl start httpd"
> If I turn the NSSEngine off it starts of cause.
> 
> In contrast to this message "ipa-getcert list -d /etc/httpd/alias/ -n
> Server-Cert" does find a certificate, if I get the output [1] right.

ipa-getcert shows certs that are tracked by certmonger but doesn't
guarantee that those certificates actually exist in the filesystem (they
did at the time tracking was started).

You need to look at the Apache NSS database:

# certutil -L -d /etc/httpd/alias

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can Load balanced HTTP service use kerberos authentication?

[Rob Crittenden via FreeIPA-users]

William Muriithi via FreeIPA-users wrote:
> Hi  Wouter,
> 
> On 11 August 2017 at 15:14,   wrote:
>> I've used shared keytabs before to create a loadbalanced squid instance.
>> This way you don't even need to use sticky balancing since all nodes that
>> have the key material will be able to decrypt TGSs for the shared service.
>> Be sure to use the -r option with ipa-getkeytab, otherwise the secret will
>> be reset. Alternatively you can just copy the keytab entries.
>>
> 
> Thank you. I got to test it this afternoon and have some follow up
> question/comment.  For one, I am not able to use the -r option/flag.
> Very odd, it don't even show up on the man page.  This is the error I
> am getting.
> 
> [root@plutonium ~]# ipa-getkeytab -r -s  lithium.eng.example.com -p
> lsf/digitalmob.eng.example.com -k /etc/krb5.keytab
> Usage: ipa-getkeytab [-qP?] [-q|--quiet] [-s|--server Server Name]
> [-p|--principal Kerberos Service Principal Name] [-k|--keytab
> Keytab File Name]
> [-e|--enctypes Comma separated encryption types list]
> [--permitted-enctypes] [-P|--password]
> [-D|--binddn DN to bind as if not using kerberos] [-w|--bindpw
> password to use if not using kerberos]
> [-?|--help] [--usage]
> [root@plutonium ~]#

-r was added in 4.0.0 so I assume you are running 3.x.

> I ended up running it without the -r flag.  However, it didn't seem to
> reset the keytab.  At least I see all the service principles I
> expected. Do you know how I can verify that the secret hasn't been
> reset?
> 
> ipa-getkeytab  -s  lithium.eng.example.com -p
> lsf/digitalmob.eng.example.com -k /etc/krb5.keytab
> 
> [root@plutonium ~]# klist -ke  /etc/krb5.keytab

You run this on each host that has executed ipa-getkeytab and compare
the KVNO. If they are different the keys were changed.

Running without the retrieve option should reset the key.

> Lastly, it looks like the clients will be aware of all the servers,
> just not the load balancer. This don't look like a great idea to me.
> For example, if one server is down, the load balance would avoid
> sending traffic to it, but since the load balancer FQDN now resolve to
> all the IP addresses involved, the clients can connect to a system
> that is currently down.  How did you get around that?

I don't follow. The load balancer should be able to detect when one of
the servers it fronts is down.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org