date:20170418

Re: [Freeipa-users] (no subject)

2017-04-18 Thread Fraser Tweedale

On Thu, Apr 13, 2017 at 04:49:59PM +0200, Tiemen Ruiten wrote:
> Hello!
> 
> As I understand from this
> 
> thread,
> it should be possible to setup a trust between FreeIPA and Samba4. My AD
> domain is clients.i.rdmedia.com, it's a subdomain of my FreeIPA domain,
> i.rdmedia.com. Therefore I added a global forwarder on the Samba AD DC to
> one of the FreeIPA replica's and lookup of SRV records in both domains
> appears to work.
> 
> However when I try to add the trust I get "ipa: ERROR an internal error has
> occurred". I ran the trust-add command with full debug logging as described
> on https://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust,
> so I can provide these logs privately upon request.
> 
We do not yet support trusts to Samba 4 AD DC.  It is an open
ticket: https://pagure.io/freeipa/issue/4866

I do not think it is a priority at this time.  Alexander (Cc) could
possibly provide an update.

Thanks,
Fraser

> I suspect some DNS-issue, as right after I try to setup the trust, dynamic
> updates stop working on the AD Domain Controller with this error:
> 
> tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  Minor
> code may provide more information, Minor = Server DNS/
> fluorine.clients.i.rdmedia@i.rdmedia.com not found in Kerberos database.
> Failed nsupdate: 1
> update(nsupdate): SRV _ldap._tcp.Default-First-Site-Name._
> sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com
> 389
> Calling nsupdate for SRV _ldap._tcp.Default-First-Site-Name._
> sites.ForestDnsZones.clients.i.rdmedia.com fluorine.clients.i.rdmedia.com
> 389 (add)
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
> ;; UPDATE SECTION:
> _ldap._tcp.Default-First-Site-Name._
> sites.ForestDnsZones.clients.i.rdmedia.com. 900 IN SRV 0 100 389
> fluorine.clients.i.rdmedia.com.
> 
> Many thanks in advance for your assistance.
> 
> 
> -- 
> Tiemen Ruiten
> Systems Engineer
> R Media

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

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

Re: [Freeipa-users] renewing cert and migrating free-ipa 3.1

2017-04-18 Thread Rob Crittenden

Umarzuki Mochlis wrote:
> Now users complaining that passwords that have been reset cannot be
> used to log in.

Passwords are completely unrelated to expired certificates.

Wow, this is really quite an old install.

The error message about communicating with CMS suggests that the CA
isn't really up. The dogtag debug log may contain more details on that.

What is the output when you use ipactl to restart the services? I have
the feeling it is catching an error that your manual restart is not.

I'd also not set the date back so far. It won't hurt but it will be the
starting date for new certificates so you'd be cheating yourself out of
8 or so months.

I'd also look at the RA agent cert to be sure it is currently correct:

$ ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -W -b
uid=ipara,ou=People,o=ipaca description

$ certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial

The description field from the ldapsearch has the format:

2;;;

The serial numbers should match. Don't do anything if they don't, just
report back the result.

rob

> I also tried resubmit getcert but 2 resubmit failed
> 
> [root@ipa ~]# getcert list
> Number of certificates and requests being tracked: 7.
> Request ID '20130112120226':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=DOA.GOV.MY
> subject: CN=CA Audit,O=DOA.GOV.MY
> expires: 2016-11-24 16:19:25 UTC
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
> "auditSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20130112120227':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
> cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=DOA.GOV.MY
> subject: CN=OCSP Subsystem,O=DOA.GOV.MY
> expires: 2016-11-24 16:18:25 UTC
> eku: id-kp-OCSPSigning
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
> "ocspSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20130112120228':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=DOA.GOV.MY
> subject: CN=CA Subsystem,O=DOA.GOV.MY
> expires: 2016-11-24 16:18:25 UTC
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
> "subsystemCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20130112120229':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate:
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
> Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=DOA.GOV.MY
> subject: CN=IPA RA,O=DOA.GOV.MY
> expires: 2016-11-24 16:18:25 UTC
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
> track: yes
> auto-renew: yes
> Request ID '20130112120230':
> status: MONITORING
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
> cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
> certificate:
> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
> cert-pki-ca',token='NSS Certificate DB'
> CA: dogtag-ipa-renew-agent
> issuer: CN=Certificate Authority,O=DOA.GOV.MY
> subject: CN=ipa.domain.com.my,O=DOA.GOV.MY
> expires: 2016-11-24 16:18:25 UTC
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/lib64/ipa/certmonger/restart_pkicad
> "Server-Cert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20130112120232':
> status: CA_UNREACHABLE
> ca-error: Server failed request, will retry: 4301 (RPC failed at
> server.  Certificate operation cannot be completed: Unable to
> communicate with CMS

[Freeipa-users] ipa-server-install fails at client phase

2017-04-18 Thread Davide Siluri

From: Davide Siluri
Sent: 14 April 2017 17:12
To: freeipa-users@redhat.com
Subject: [Freeipa-users] ipa-server-install fails at client phase

Hello Ryan,

I had that same issue with FreeIPA 4.4 on RH 7.3.

?

In my case IPA installation linked a wrong dependency with python36u-mod_wsgi.

Remove python36u package and install mod_wsgi (in my case 
mod_wsgi-3.4-12.el7_0.x86_64) before running IPA install procedure again.

That should solve the problem.

Regards

Davide
-- 
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] renewing cert and migrating free-ipa 3.1

2017-04-18 Thread Umarzuki Mochlis

below are from httpd error log

[Thu Feb 18 16:28:06.351007 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: user_find(u'yusma', sizelimit=0, pkey_only=True):
SUCCESS
[Thu Feb 18 16:28:06.400453 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: batch: user_show(u'nisa', all=True): SUCCESS
[Thu Feb 18 16:28:06.412753 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: batch: user_show(u'noryusmaniza', all=True):
SUCCESS
[Thu Feb 18 16:28:06.428103 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: batch: user_show(u'yusmayusof', all=True):
SUCCESS
[Thu Feb 18 16:28:06.428335 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: batch(({u'params': [[u'nisa'], {u'all': True}],
u'method': u'user_show'}, {u'params': [[u'noryusmaniza'], {u'all':
True}], u'method': u'user_show'}, {u'params': [[u'yusmayusof'],
{u'all': True}], u'method': u'user_show'})): SUCCESS
[Thu Feb 18 16:28:09.254484 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: batch: user_show(u'yusmayusof', rights=True,
all=True): SUCCESS
[Thu Feb 18 16:28:09.308107 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: batch: pwpolicy_show(None, rights=True,
user=u'yusmayusof', all=True): SUCCESS
[Thu Feb 18 16:28:09.416227 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: batch: krbtpolicy_show(u'yusmayusof',
rights=True, all=True): SUCCESS
[Thu Feb 18 16:28:09.416483 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: batch(({u'params': [[u'yusmayusof'], {u'all':
True, u'rights': True}], u'method': u'user_show'}, {u'params': [[],
{u'all': True, u'user': u'yusmayusof', u'rights': True}], u'method':
u'pwpolicy_show'}, {u'params': [[u'yusmayusof'], {u'all': True,
u'rights': True}], u'method': u'krbtpolicy_show'})): SUCCESS
[Thu Feb 18 16:28:09.921130 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: user_find(None): SUCCESS
[Thu Feb 18 16:28:27.176668 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: passwd(u'yusmayusof', u'', None): SUCCESS
[Thu Feb 18 16:28:27.331989 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: batch: user_show(u'yusmayusof', rights=True,
all=True): SUCCESS
[Thu Feb 18 16:28:27.382532 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: batch: pwpolicy_show(None, rights=True,
user=u'yusmayusof', all=True): SUCCESS
[Thu Feb 18 16:28:27.486929 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: batch: krbtpolicy_show(u'yusmayusof',
rights=True, all=True): SUCCESS
[Thu Feb 18 16:28:27.487178 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: batch(({u'params': [[u'yusmayusof'], {u'all':
True, u'rights': True}], u'method': u'user_show'}, {u'params': [[],
{u'all': True, u'user': u'yusmayusof', u'rights': True}], u'method':
u'pwpolicy_show'}, {u'params': [[u'yusmayusof'], {u'all': True,
u'rights': True}], u'method': u'krbtpolicy_show'})): SUCCESS
[Thu Feb 18 16:28:27.969435 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: user_find(None): SUCCESS
[Thu Feb 18 16:29:22.017394 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: passwd(u'yusmayusof', u'', None): SUCCESS
[Thu Feb 18 16:29:22.169817 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: batch: user_show(u'yusmayusof', rights=True,
all=True): SUCCESS
[Thu Feb 18 16:29:22.221379 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: batch: pwpolicy_show(None, rights=True,
user=u'yusmayusof', all=True): SUCCESS
[Thu Feb 18 16:29:22.325846 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: batch: krbtpolicy_show(u'yusmayusof',
rights=True, all=True): SUCCESS
[Thu Feb 18 16:29:22.326098 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: batch(({u'params': [[u'yusmayusof'], {u'all':
True, u'rights': True}], u'method': u'user_show'}, {u'params': [[],
{u'all': True, u'user': u'yusmayusof', u'rights': True}], u'method':
u'pwpolicy_show'}, {u'params': [[u'yusmayusof'], {u'all': True,
u'rights': True}], u'method': u'krbtpolicy_show'})): SUCCESS
[Thu Feb 18 16:29:22.801354 2016] [:error] [pid 311] ipa: INFO:
ad...@domain.com.my: user_find(None): SUCCESS
[Thu Feb 18 16:31:55.029022 2016] [:error] [pid 310] ipa: ERROR:
AuthManager.logout.xmlserver_session: session_data does not contain
ccache_data
[Thu Feb 18 16:31:55.029222 2016] [:error] [pid 310] ipa: INFO:
ad...@domain.com.my: session_logout(): SUCCESS
[Thu Feb 18 16:35:35.585717 2016] [:error] [pid 377] SSL Library
Error: -12195 Peer does not recognize and trust the CA that issued
your certificate
[Thu Feb 18 16:36:59.015795 2016] [auth_kerb:error] [pid 377] [client
10.19.82.43:54553] gss_accept_sec_context() failed: No credentials
were supplied, or the credentials were unavailable or inaccessible (,
Unknown error), referer: https://ipa.domain.com.my/ipa/ui/
[root@ipa ~]# date
Thu Feb 18 16:37:19 MYT 2016

-- 
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] Using different HTTP/ principal for FreeIPA WebUI

2017-04-18 Thread Jan Pazdziora


Hello,

I'm setting up two FreeIPA replicas with load balancer in front of
them per

https://www.adelton.com/freeipa/freeipa-behind-load-balancer

Things work when authenticating with login and password.

I then want to enable GSSAPI/Negotiate for the WebUI. For that, I
create host and service for the load balancer (webipa.example.com
and HTTP/webipa.example.com), I add the principal to the
ipa-http-delegation rule via

ipa servicedelegationrule-add-member ipa-http-delegation 
--principals=HTTP/webipa.example.com

and I fetch the keytab for the principal on the backend nodes.
When I replace the original /etc/httpd/conf/ipa.keytab file with
the new keytab with just the keys for HTTP/webipa.example.com, I can
authenticate with my Firefox via Kerberos.

However, I'm afraid that by removing the original keys for
HTTP/ipa1.int.example.com (resp.  HTTP/ipa2.int.example.com)
principal from /etc/httpd/conf/ipa.keytab, I might break something,
at least the ability to access those backend machines via GSSAPI
directly (not via the load balancer).

When I add the frontend keys to the original keytab file with ktutil
with

read_kt /etc/httpd/conf/frontend.keytab
write_kt /etc/httpd/conf/ipa.keytab
quit

authentication fails with

ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic 
failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more 
information (Matching credential not found (filename: 
/var/run/ipa_memcached/krbcc_1222))

When I try to start with the frontend.keytab content by copying it
over to ipa.keytab and append the backend keyts to that file -- then
I can Kerberos-authenticate via the frontend but not with going to the
backend URL directly.

So it looks like only the first principal in the keytab is considered
at whatever stage which fails during the GSSAPI authentication.

Any hints as to how to debug the setup further would be appreciated.
This is with freeipa-server-4.4.4-1.fc25.

Thank you,

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

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

Re: [Freeipa-users] renewing cert and migrating free-ipa 3.1

2017-04-18 Thread Umarzuki Mochlis

please ignore that domain because I did not mask it properly

-- 
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] renewing cert and migrating free-ipa 3.1

2017-04-18 Thread Umarzuki Mochlis

Now users complaining that passwords that have been reset cannot be
used to log in.

I also tried resubmit getcert but 2 resubmit failed

[root@ipa ~]# getcert list
Number of certificates and requests being tracked: 7.
Request ID '20130112120226':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=DOA.GOV.MY
subject: CN=CA Audit,O=DOA.GOV.MY
expires: 2016-11-24 16:19:25 UTC
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20130112120227':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=DOA.GOV.MY
subject: CN=OCSP Subsystem,O=DOA.GOV.MY
expires: 2016-11-24 16:18:25 UTC
eku: id-kp-OCSPSigning
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20130112120228':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=DOA.GOV.MY
subject: CN=CA Subsystem,O=DOA.GOV.MY
expires: 2016-11-24 16:18:25 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"subsystemCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20130112120229':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=DOA.GOV.MY
subject: CN=IPA RA,O=DOA.GOV.MY
expires: 2016-11-24 16:18:25 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
track: yes
auto-renew: yes
Request ID '20130112120230':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin='932018712055'
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=DOA.GOV.MY
subject: CN=ipa.domain.com.my,O=DOA.GOV.MY
expires: 2016-11-24 16:18:25 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_pkicad
"Server-Cert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20130112120232':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 4301 (RPC failed at
server.  Certificate operation cannot be completed: Unable to
communicate with CMS (Internal Server Error)).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM-MY/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=DOA.GOV.MY
subject: CN=ipa.domain.com.my,O=DOA.GOV.MY
expires: 2016-12-16 16:18:27 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv DOMAIN-COM-MY
track: yes
auto-renew: yes
Request ID '20130112120734':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: 4301 (RPC failed at
server.  Certificate operation cannot be completed: Unable to
communicate with CMS (Internal Server Error)).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA

Re: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address

2017-04-18 Thread David Goudet


Hi,

Nobody has response about my questions?

The main question is: Is it possible to configure SSSD to update DNS (option 
dyndns_update) with only IP address "primary" in ip addr list or which is used 
to FreeIPA server communication (-IP1- used on TCP binding)?

Thank you for your help.

Best regards,


On 03/27/2017 06:34 PM, David Goudet wrote:

Hi,

Thanks to dyndns_update=True parameter, SSSD service on client machine updating 
host DNS entry in FreeIPA.
Everything is fine on machines which have only one IP adress on network 
interface.
I have problem with machines which have more that one IP address on network 
interface: if machine have two IP address, SSSD update host DNS entry with 
these two IP address.

To reproduce the problem:
Host have -IP1- and i add -IP2-
ip addr add -IP2-/26 dev em1

ip addr list:
em1:  mtu 1496 qdisc mq state UP qlen 1000
 link/ether 
 inet -IP1-/26 brd  scope global em1
 inet -IP2-/26 scope global secondary em1
valid_lft forever preferred_lft forever

DNS resolution (dig) before restarting sssd returns only -IP1-. After restarting 
sssd returns -IP1- & -IP2-

In dyndns_update manpage, we have "The IP address of the IPA LDAP connection is used 
for the updates", what does it means? Is it IP address of the DNS server (used to 
update the DNS entry)? or is it IP address on client machine used during LDAP TCP bind 
(-IP1- in my case)?

dyndns_update (boolean)
Optional. This option tells SSSD to automatically update the DNS 
server built into FreeIPA v2 with the IP address of this client.
The update is secured using GSS-TSIG. The IP address of the IPA 
LDAP connection is used for the updates, if it is not otherwise
specified by using the “dyndns_iface” option.

Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on 
client machine?
Is it possible to configure SSSD to update DNS with only IP address "primary" 
in ip addr list or which is used to FreeIPA server communication (-IP1- used on TCP 
binding)?

My environment is:
Client: Centos 7.2
sssd-common-1.13.0-40.el7_2.12.x86_64
sssd-ipa-1.13.0-40.el7_2.12.x86_64
sssd-1.13.0-40.el7_2.12.x86_64
sssd-client-1.13.0-40.el7_2.12.x86_64
FreeIPA server: Centos 6.7
ipa-server-3.0.0-47.el6.centos.2.x86_64
bind-9.8.2-0.30.rc1.el6_6.3.x86_64
bind-utils-9.8.2-0.37.rc1.el6_7.7.x86_64
bind-libs-9.8.2-0.37.rc1.el6_7.7.x86_64
rpcbind-0.2.0-11.el6_7.x86_64
bind-libs-9.8.2-0.30.rc1.el6_6.3.x86_64
rpcbind-0.2.0-11.el6.x86_64
bind-dyndb-ldap-2.3-8.el6.x86_64
bind-9.8.2-0.37.rc1.el6_7.7.x86_64


SSSD configuration on client:
[domain/]

debug_level=18
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = 
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
chpass_provider = ipa
dyndns_update = True
ipa_server = _srv_, ds01., ds01.
dns_discovery_domain = 


Named FreeIPA logs:
---
Mar 27 17:03:57 ds01. named[6607]: client -IP1-#36331: updating zone '/IN': deleting rrset at '' A
Mar 27 17:03:57 ds01. named[6607]: update_record (psearch) failed, dn 
'idnsName=2,idnsname=.in-addr.arpa.,cn=dns,dc=yyy,dc=xxx' change type 0x4. 
Records can be outdated, run `rndc reload`: not found
Mar 27 17:03:57 ds01. named[6607]: zone /IN: sending 
notifies (serial 1490615011)
Mar 27 17:03:57 ds01. named[6607]: client -IP1-#46187: updating zone 
'/IN': deleting rrset at '.' 
Mar 27 17:03:57 ds01. named[6607]: client -IP1-#54691: updating zone 
'/IN': adding an RR at '.' A
Mar 27 17:03:57 ds01. named[6607]: client -IP1-#54691: updating zone 
'/IN': adding an RR at '.' A
Mar 27 17:03:57 ds01. named[6607]: zone .in-addr.arpa/IN: 
sending notifies (serial 1490627037)
Mar 27 17:04:02 ds01. named[6607]: zone /IN: sending 
notifies (serial 1490627038)

SSSD trace log on client during sssd restart:
---
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [ipa_dyndns_update_send] 
(0x0400): Performing update
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_id_op_connect_step] 
(0x4000): reusing cached connection
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_id_op_destroy] (0x4000): 
releasing operation connection
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_is_address] (0x4000): 
[.] does not look like an IP address
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_step] 
(0x2000): Querying DNS
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_dns_query] (0x0100): 
Trying to resolve A record of '.' in DNS
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_request_timeout] 
(0x2000): Scheduling a timeout of 6 seconds
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_timeout_watcher] 
(0x2000): Scheduling DNS timeout watcher
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] [unschedule_timeout_watcher] 
(0x4000): Unscheduling DNS timeout watcher
(Mon Mar 27 17:03:56 2017) [sssd[be[]]] 
[resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply
(Mon Mar 27

Re: [Freeipa-users] Using fqdn in /etc/hostname causes duplicate domain in DHCP dyndns update

2017-04-18 Thread Kees Bakker

It's a two level domain.

BTW. Something to add. It happens with an Ubuntu Zesty (17.04) client.
This has freeipa 4.4.x while the rest of the network (and server) runs with
freeipa 4.3.x

On 15-04-17 17:29, Jake wrote:
> is your "mydomain" actually a one level tld or example.com
>
> - Original Message -
> From: "Kees Bakker" 
> To: "freeipa-users" 
> Sent: Thursday, April 13, 2017 10:30:33 AM
> Subject: [Freeipa-users] Using fqdn in /etc/hostname causes duplicate domain 
> in DHCP dyndns update
>
> Hey,
>
> Hopefully someone here can hint me towards a (easier) solution.
>
> In short, for correct DHCP-DDNS updates there should be a non-fqdn in 
> /etc/hostname
> To install IPA client I am forced to have a fqdn in /etc/hostname. But now 
> the DHCP-DDNS
> results in duplicated domain portion of the DNS entries.
>
> The details.
> We have a FreeIPA environment with DNS and DHCP. I've configured bind and
> dhcpd to do DDNS. For the most part it is working as expected.
>
> When the hostname of a system is a non-fqdn the end result is what I want to 
> see. Say I have
> /etc/hostname: test02
> then after it started up there is a new forward map (using "mydomain" here 
> instead of the real thing).
>test01 -> 172.16.16.252
> and a reverse map in 16.16.172.in-addr.arpa zone
>252 -> test02.mydomain
>
> Some lines from /var/log/syslog
> dhcpd[82333]: DHCPOFFER on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via 
> eno1
> named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating 
> zone 'mydomain/IN': adding an RR at 'test02.mydomain' A 172.16.16.252
> dhcpd[82333]: DHCPREQUEST for 172.16.16.252 (172.16.16.75) from 
> 00:16:3e:8e:91:12 (test02) via eno1
> dhcpd[82333]: DHCPACK on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1
> named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating 
> zone 'mydomain/IN': adding an RR at 'test02.mydomain' DHCID 
> AAAB6QGH0W+JCSMwrj9sQVCeh5PToZAmWZvMpgiEtXHrZgE=
> dhcpd[82333]: Added new forward map from test02.mydomain to 172.16.16.252
> named-pkcs11[82428]: client 172.16.16.75#23238/key dhcp_updater: updating 
> zone '16.16.172.in-addr.arpa/IN': adding an RR at 
> '252.16.16.172.in-addr.arpa' PTR test02.mydomain.
> dhcpd[82333]: Added reverse map from 252.16.16.172.in-addr.arpa. to 
> test02.mydomain
>
> However, when I want to add this system as a IPA client I am forced to
> fill in a fqdn in /etc/hostname. So I change /etc/hostname to have 
> test01.mydomain
> The provisioning succeeds and all seems well.
>
> But after a reboot the system requests DHCP to register as test01.mydomain. 
> And
> the DHCP server does a DNS update for test01.mydomain.mydomain.
> The DNS zone for mydomain now has
> test01 for all the SSHFP records
> test01.mydomain for the A record
> The reverse map for 16.16.172.in-addr.arpa has
> 231 -> test01.mydomain.mydomain
>
> named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating 
> zone 'mydomain/IN': deleting an RR at test02.mydomain A
> dhcpd[4550]: DHCPREQUEST for 172.16.16.252 from 00:16:3e:8e:91:12 (test02) 
> via eno1
> dhcpd[4550]: DHCPACK on 172.16.16.252 to 00:16:3e:8e:91:12 (test02.mydomain) 
> via eno1
> dhcpd[4550]: Removed forward map from test02.mydomain to 172.16.16.252
> named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating 
> zone 'mydomain/IN': deleting an RR at test02.mydomain DHCID
> named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating 
> zone 'mydomain/IN': adding an RR at 'test02.mydomain.mydomain' A 172.16.16.252
> named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating 
> zone 'mydomain/IN': adding an RR at 'test02.mydomain.mydomain' DHCID 
> AAAB+5EmVxuf4utDMDZxjqAiqIds6Briv5awEp5W3whNsLc=
> dhcpd[4550]: Added new forward map from test02.mydomain.mydomain to 
> 172.16.16.252
> named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating 
> zone '16.16.172.in-addr.arpa/IN': adding an RR at 
> '252.16.16.172.in-addr.arpa' PTR test02.mydomain.mydomain.
> dhcpd[4550]: Added reverse map from 252.16.16.172.in-addr.arpa. to 
> test02.mydomain.mydomain
>
>
> To work around I then change the /etc/hostname back to test01, restart
> the network and everything if fine afterwards.
>
> named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating 
> zone 'mydomain/IN': deleting an RR at test02.mydomain.mydomain A
> dhcpd[4550]: DHCPRELEASE of 172.16.16.252 from 00:16:3e:8e:91:12 
> (test02.mydomain) via eno1 (found)
> dhcpd[4550]: Removed forward map from test02.mydomain.mydomain to 
> 172.16.16.252
> named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating 
> zone 'mydomain/IN': deleting an RR at test02.mydomain.mydomain DHCID
> dhcpd[4550]: DHCPOFFER on 172.16.16.252 to 00:16:3e:8e:91:12 (test02) via eno1
> named-pkcs11[82428]: client 172.16.16.75#61759/key dhcp_updater: updating 
> zone 'mydomain/IN': update

Re: [Freeipa-users] (no subject)

Re: [Freeipa-users] renewing cert and migrating free-ipa 3.1

[Freeipa-users] ipa-server-install fails at client phase

Re: [Freeipa-users] renewing cert and migrating free-ipa 3.1

[Freeipa-users] Using different HTTP/ principal for FreeIPA WebUI

Re: [Freeipa-users] renewing cert and migrating free-ipa 3.1

Re: [Freeipa-users] renewing cert and migrating free-ipa 3.1

Re: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address

Re: [Freeipa-users] Using fqdn in /etc/hostname causes duplicate domain in DHCP dyndns update

9 matches

Site Navigation

Mail list logo

Footer information