Re: [Freeipa-users] named-pkcs11 doesn't start after bind update

[Roberto Cornacchia]

Ben and Petr,

Thanks for your inputs, I'll keep an eye on those bug reports.

Roberto

On 22 July 2016 at 09:51, Petr Spacek  wrote:

> On 22.7.2016 04:43, Ben Lipton wrote:
> > I'm not familiar enough with Fedora release engineering to know how this
> gets
> > fixed permanently, but I'll share some investigation I've done.
> >
> > This appears to be due to a change in the selinux-policy-targeted
> package that
> > happened recently. As of the latest version, named-pkcs11 tries to run
> as type
> > named_t instead of unconfined_service_t, but it isn't allowed to read the
> > files from IPA [1]. When I downgraded to the selinux-policy and
> > selinux-policy-targeted packages from [2] I was able to start
> named-pkcs11, so
> > that might be a workaround you can use for now. Ultimately, the patch
> that
> > fixes [3] might need to be backported to F23.
>
> This is being tracked as
> https://bugzilla.redhat.com/show_bug.cgi?id=1357665
>
> Stay tuned.
>
> Petr^2 Spacek
>
> >
> > Ben
> >
> > [1]
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.756:705): avc:  denied  { read } for
> pid=11616
> > comm="named-pkcs11" name="tokens" dev="dm-0" ino=26318195
> > scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=dir permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.756:706): avc:  denied  { getattr } for
> > pid=11616 comm="named-pkcs11"
> >
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/token.object"
> > dev="dm-0" ino=609982 scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.756:707): avc:  denied  { read write } for
> > pid=11616 comm="named-pkcs11" name="generation" dev="dm-0" ino=731584
> > scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.757:708): avc:  denied  { open } for
> pid=11616
> > comm="named-pkcs11"
> >
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
> > dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.757:709): avc:  denied  { lock } for
> pid=11616
> > comm="named-pkcs11"
> >
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
> > dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> >
> > [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=758088
> > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1333106
> >
> > On 07/21/2016 05:51 PM, Roberto Cornacchia wrote:
> >> UPDATE:
> >>
> >> Tried again the whole procedure with ipa-dns-install, and it DOES work
> with
> >> SElinux disable, and still fails with SElinux enabled.
> >>
> >> So the error "Failed to enumerate object store in
> /var/lib/softhsm/tokens/"
> >> makes sense.
> >>
> >> Can someone help me fix it?
> >>
> >> $ ll -Z /var/lib/ipa/dnssec/
> >> total 12
> >> -rwxrwx---. 1 ods named unconfined_u:object_r:ipa_var_lib_t:s0   30 Jul
> 21
> >> 22:50 softhsm_pin*
> >> drwxrws---. 3 ods named unconfined_u:object_r:ipa_var_lib_t:s0 4096 Jul
> 21
> >> 22:50 tokens/
> >>
> >>
> >>
> >> On 21 July 2016 at 23:11, Roberto Cornacchia <
> roberto.cornacc...@gmail.com
> >> <mailto:roberto.cornacc...@gmail.com>> wrote:
> >>
> >> - FC23
> >> - IPA 4.2.4
> >>
> >> After a dnf update, bind was updated (no ipa updates),
> >> and named-pkcs11 doesn't start anymore.
> >>
> >>
> >> $ /usr/sbin/named-pkcs11 -d 9 -g
> >> 21-Jul-2016 23:08:50.332 starting BIND
> >> 9.10.3-P4-RedHat-9.10.3-13.P4.fc23  -d 9 -g
> >> 21-Jul-2016 23:08:50.332 built with
> >> '--build=x86_64-redhat-linux-gnu' &#x

Re: [Freeipa-users] named-pkcs11 doesn't start after bind update

[Roberto Cornacchia]

UPDATE:

Tried again the whole procedure with ipa-dns-install, and it DOES work with
SElinux disable, and still fails with SElinux enabled.

So the error "Failed to enumerate object store in /var/lib/softhsm/tokens/"
makes sense.

Can someone help me fix it?

$ ll -Z /var/lib/ipa/dnssec/
total 12
-rwxrwx---. 1 ods named unconfined_u:object_r:ipa_var_lib_t:s0   30 Jul 21
22:50 softhsm_pin*
drwxrws---. 3 ods named unconfined_u:object_r:ipa_var_lib_t:s0 4096 Jul 21
22:50 tokens/



On 21 July 2016 at 23:11, Roberto Cornacchia 
wrote:

> - FC23
> - IPA 4.2.4
>
> After a dnf update, bind was updated (no ipa updates), and named-pkcs11
> doesn't start anymore.
>
>
> $ /usr/sbin/named-pkcs11 -d 9 -g
> 21-Jul-2016 23:08:50.332 starting BIND 9.10.3-P4-RedHat-9.10.3-13.P4.fc23
>  -d 9 -g
> 21-Jul-2016 23:08:50.332 built with '--build=x86_64-redhat-linux-gnu'
> '--host=x86_64-redhat-linux-gnu' '--program-prefix='
> '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
> '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
> '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
> '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
> '--mandir=/usr/share/man' '--infodir=/usr/share/info'
> '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var'
> '--enable-threads' '--enable-ipv6' '--enable-filter-' '--with-pic'
> '--disable-static' '--disable-openssl-version-check'
> '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-geoip'
> '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so'
> '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes'
> '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes'
> '--with-gssapi=yes' '--disable-isc-spnego' '--enable-fixed-rrset'
> '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
> '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu'
> 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic'
> 'LDFLAGS=-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
> 'CPPFLAGS= -DDIG_SIGCHASE'
> 21-Jul-2016 23:08:50.332
> 
> 21-Jul-2016 23:08:50.332 BIND 9 is maintained by Internet Systems
> Consortium,
> 21-Jul-2016 23:08:50.332 Inc. (ISC), a non-profit 501(c)(3) public-benefit
> 21-Jul-2016 23:08:50.332 corporation.  Support and training for BIND 9 are
> 21-Jul-2016 23:08:50.332 available at https://www.isc.org/support
> 21-Jul-2016 23:08:50.332
> 
> 21-Jul-2016 23:08:50.332 adjusted limit on open files from 4096 to 1048576
> 21-Jul-2016 23:08:50.332 found 2 CPUs, using 2 worker threads
> 21-Jul-2016 23:08:50.332 using 2 UDP listeners per interface
> 21-Jul-2016 23:08:50.332 using up to 21000 sockets
> 21-Jul-2016 23:08:50.332 Registering DLZ_dlopen driver
> 21-Jul-2016 23:08:50.332 Registering SDLZ driver 'dlopen'
> 21-Jul-2016 23:08:50.332 Registering DLZ driver 'dlopen'
> 21-Jul-2016 23:08:50.335 initializing DST: PKCS#11 initialization failed
> 21-Jul-2016 23:08:50.335 exiting (due to fatal error)
>
> journalctl shows:
>
> named-pkcs11[9085]: ObjectStore.cpp(59): Failed to enumerate object store
> in /var/lib/softhsm/tokens/
> named-pkcs11[9085]: SoftHSM.cpp(476): Could not load the object store
>
>
>
> $ ll -Z /var/lib/ipa/dnssec/
> total 12
> -rwxrwx---. 1 ods named unconfined_u:object_r:ipa_var_lib_t:s0   30 Jul 21
> 22:50 softhsm_pin*
> drwxrws---. 3 ods named unconfined_u:object_r:ipa_var_lib_t:s0 4096 Jul 21
> 22:50 tokens/
>
>
> - I have seen https://fedorahosted.org/freeipa/ticket/5520 , it doesn't
> help.
> - With setenforce 0, same error.
> - I have run ipa-dns-install, it recreates named.conf, tokens
> etc. named-pkcs11 still doesn't start.
>
>
> Please, any idea?
>
> Roberto
>
-- 
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] named-pkcs11 doesn't start after bind update

[Roberto Cornacchia]

- FC23
- IPA 4.2.4

After a dnf update, bind was updated (no ipa updates), and named-pkcs11
doesn't start anymore.


$ /usr/sbin/named-pkcs11 -d 9 -g
21-Jul-2016 23:08:50.332 starting BIND 9.10.3-P4-RedHat-9.10.3-13.P4.fc23
 -d 9 -g
21-Jul-2016 23:08:50.332 built with '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
'--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var'
'--enable-threads' '--enable-ipv6' '--enable-filter-' '--with-pic'
'--disable-static' '--disable-openssl-version-check'
'--includedir=/usr/include/bind9' '--with-tuning=large' '--with-geoip'
'--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so'
'--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes'
'--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes'
'--with-gssapi=yes' '--disable-isc-spnego' '--enable-fixed-rrset'
'--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
'--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic'
'LDFLAGS=-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
'CPPFLAGS= -DDIG_SIGCHASE'
21-Jul-2016 23:08:50.332

21-Jul-2016 23:08:50.332 BIND 9 is maintained by Internet Systems
Consortium,
21-Jul-2016 23:08:50.332 Inc. (ISC), a non-profit 501(c)(3) public-benefit
21-Jul-2016 23:08:50.332 corporation.  Support and training for BIND 9 are
21-Jul-2016 23:08:50.332 available at https://www.isc.org/support
21-Jul-2016 23:08:50.332

21-Jul-2016 23:08:50.332 adjusted limit on open files from 4096 to 1048576
21-Jul-2016 23:08:50.332 found 2 CPUs, using 2 worker threads
21-Jul-2016 23:08:50.332 using 2 UDP listeners per interface
21-Jul-2016 23:08:50.332 using up to 21000 sockets
21-Jul-2016 23:08:50.332 Registering DLZ_dlopen driver
21-Jul-2016 23:08:50.332 Registering SDLZ driver 'dlopen'
21-Jul-2016 23:08:50.332 Registering DLZ driver 'dlopen'
21-Jul-2016 23:08:50.335 initializing DST: PKCS#11 initialization failed
21-Jul-2016 23:08:50.335 exiting (due to fatal error)

journalctl shows:

named-pkcs11[9085]: ObjectStore.cpp(59): Failed to enumerate object store
in /var/lib/softhsm/tokens/
named-pkcs11[9085]: SoftHSM.cpp(476): Could not load the object store



$ ll -Z /var/lib/ipa/dnssec/
total 12
-rwxrwx---. 1 ods named unconfined_u:object_r:ipa_var_lib_t:s0   30 Jul 21
22:50 softhsm_pin*
drwxrws---. 3 ods named unconfined_u:object_r:ipa_var_lib_t:s0 4096 Jul 21
22:50 tokens/


- I have seen https://fedorahosted.org/freeipa/ticket/5520 , it doesn't
help.
- With setenforce 0, same error.
- I have run ipa-dns-install, it recreates named.conf, tokens
etc. named-pkcs11 still doesn't start.


Please, any idea?

Roberto
-- 
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] Unspecified GSS failure. No credentials cache found

[Roberto Cornacchia]

Hi there,

Although I can't see anything failing, the logs of all clients in my IPA
domain (FC22, freeipa 4.1.4) contain lots of these failures every day:

nov 23 10:43:34 hadron.hq.example.com gssproxy[742]: (OID: { 1 2 840 113554
1 2 2 }) Unspecified GSS failure.  Minor code may provide more information,
No credentials cache found


Do you have suggestions on how to find out what the problem might be?
Or is this something I should not worry about?

Thanks, Roberto
-- 
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] ssh_exchange_identification: Connection closed by remote host

[Roberto Cornacchia]

Hmm, please forgive me.
It appears that sshd was NOT running on hadron.

I HAD checked before, but ... I don't know... a big ball of wibbily wobbly
timey wimey...stuff must have happened.

Sorry for the waste of time.

On 28 August 2015 at 17:10, Roberto Cornacchia  wrote:

> Hi,
>
> I have two hosts, "photon" and "hadron", and an LDAP user "roberto".
> The user can login successfully on both machines.
>
> The SSH pub key is uploaded
> .
> Running "sss_ssh_authorizedkeys roberto" from both clients returns the
> same key.
>
> Port 22 is open on both clients, sshd is running on both clients.
>
> On both client, /etc/ssh/ssh_config is:
> Host *
> GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts
> PubkeyAuthentication yes
> ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
> GSSAPIAuthentication yes
>
> On both clients, /etc/ssh/sshs_config is:
> KerberosAuthentication no
> PubkeyAuthentication yes
> UsePAM yes
> AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
> GSSAPIAuthentication yes
> AuthorizedKeysCommandUser nobody
>
>
> However, ssh from hadron to photon works, the other way around doesn't:
>
> roberto@photon $ ssh -vv hadron
> OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 56: Applying options for *
> debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p
> 22 hadron
> debug1: permanently_drop_suid: 117206
> debug1: identity file /home/roberto/.ssh/id_rsa type 1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_ecdsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_ecdsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_ed25519 type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/roberto/.ssh/id_ed25519-cert type -1
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_6.9
> *ssh_exchange_identification: Connection closed by remote host*
>
>
> If I include a few other cases, this is the summary:
> - photon to hadron FAILS
> - photon to photon SUCCEEDS
> - photon to ipa server SUCCEEDS
> - photon to (non-ipa-client) FAILS before asking password (no keypair
> suthentication expected here)
>
> - hadron to photon SUCCEEDS
> - hadron to hadron FAILS
> - hadron to ipa server SUCCEEDS
> - hadron to (non-ipa-client) FAILS before asking password (no keypair
> suthentication expected here)
>
> I know that the error above is quite generic, so I don't expect someone
> can point out the exact cause, but perhaps someone can help me debug this?
> What could I look at?
>
> Thanks,
> Roberto
>
-- 
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] ssh_exchange_identification: Connection closed by remote host

[Roberto Cornacchia]

Hi,

I have two hosts, "photon" and "hadron", and an LDAP user "roberto".
The user can login successfully on both machines.

The SSH pub key is uploaded
.
Running "sss_ssh_authorizedkeys roberto" from both clients returns the same
key.

Port 22 is open on both clients, sshd is running on both clients.

On both client, /etc/ssh/ssh_config is:
Host *
GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts
PubkeyAuthentication yes
ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
GSSAPIAuthentication yes

On both clients, /etc/ssh/sshs_config is:
KerberosAuthentication no
PubkeyAuthentication yes
UsePAM yes
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
GSSAPIAuthentication yes
AuthorizedKeysCommandUser nobody


However, ssh from hadron to photon works, the other way around doesn't:

roberto@photon $ ssh -vv hadron
OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p
22 hadron
debug1: permanently_drop_suid: 117206
debug1: identity file /home/roberto/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/roberto/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/roberto/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/roberto/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/roberto/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/roberto/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/roberto/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/roberto/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
*ssh_exchange_identification: Connection closed by remote host*


If I include a few other cases, this is the summary:
- photon to hadron FAILS
- photon to photon SUCCEEDS
- photon to ipa server SUCCEEDS
- photon to (non-ipa-client) FAILS before asking password (no keypair
suthentication expected here)

- hadron to photon SUCCEEDS
- hadron to hadron FAILS
- hadron to ipa server SUCCEEDS
- hadron to (non-ipa-client) FAILS before asking password (no keypair
suthentication expected here)

I know that the error above is quite generic, so I don't expect someone can
point out the exact cause, but perhaps someone can help me debug this? What
could I look at?

Thanks,
Roberto
-- 
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] LDAP user as client administrator

[Roberto Cornacchia]

In Fedora, adding a local user to the group "wheel" makes it administrator
on that machine. In Gnome, you see this as the distinction between a
"Normal" and and "Administrator" account.

If the user is an LDAP user, how do we achieve the same?
-- 
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] Kerberized NFS with Synology NAS

[Roberto Cornacchia]

Thanks Alexander,

That's the confirmation I was looking for. Indeed the Synology guy admitted
it was their limitation.

I have already made a feature request for SSSD.

I guess for now I will just get it running with sec=sys.

Best regards, Roberto


On 20 August 2015 at 11:32, Alexander Bokovoy  wrote:

> On Thu, 20 Aug 2015, Roberto Cornacchia wrote:
>
>> I had Synology support inspect my configuration.
>>
>> They said that the authorization for the mapping looks for attribute
>> "GSSAuthName" in LDAP, but doesn't find it. Therefore, they fall back to
>> mapping it to nobody.
>>
>> Does this make sense to you? Is it true that GSSAuthName attribute isn't
>> there?
>>
> FreeIPA does not use UMich LDAP schema developed for NFS. Instead, as we
> store
> Kerberos principals in LDAP, for each Kerberos principal there is always
> krbPrincipalName attribute available.
>
> But on SSSD clients we instead recommend using SSSD-based identity
> mapping in /etc/idmap.conf (using sss module) as it is relying on SSSD
> caching capabilities and in general is more performance efficient. For
> direct use of UMich LDAP module in NFSv4 idmap you would have idmapd
> module to query LDAP server on each GSSAPI connection and since there is
> no state umich_ldap.so module, it will re-connect to LDAP every time
> which is highly inefficient.
>
> That's why I recommended to suggest Synology to integrate SSSD in their
> OS and have real benefits in improved Kerberos/AD/LDAP/FreeIPA support.
>
>
>
>>
>>
>> On 13 August 2015 at 16:34, Alexander Bokovoy 
>> wrote:
>>
>> On Thu, 13 Aug 2015, Roberto Cornacchia wrote:
>>>
>>> After some more investigation, I feel the problem I described can be
>>>> considered off topic, sorry about that. Initially I had the impression
>>>> it
>>>> could have been more freeIPA-related.
>>>> It is sometimes difficult to tell whether the issue would show up
>>>> regardless of using freeIPA or not.
>>>>
>>>> Should anyone be curious, these are my findings about using a Synology
>>>> disk
>>>> station for NFSv4+krb5 exports in my freeIPA domain:
>>>>
>>>> - Still no idea why I see all those "Unspecified GSS failure" from
>>>> gssproxy
>>>> on the client side. Google tells me that many before me have wondered
>>>> about
>>>> it. Has anyone a clue?
>>>>
>>>> - The NFS4+krb5 mounting works, but what I ran into is the "nobody"
>>>> issue.
>>>> NFSv4 relies on idmapd to map users correctly, but this goes wrong,
>>>> hence
>>>> the "nobody" issue
>>>>
>>>> - One first problem is that I had not set the domain. My bad. Fixed and
>>>> got
>>>> one step further.
>>>>in idmapd.conf: Domain = hq.spinque.com
>>>>
>>>> - The second problem is that idmapd.conf in my synology says:
>>>>Method=nsswitch
>>>>GSS-Methods=static,synomap
>>>>
>>>>  No idea what "synomap" would be, but I guess GSS-Methods should be more
>>>> like "static,nsswitch,synomap"
>>>>  Indeed, everything works fine if I make static mappings for each LDAP
>>>> user to a local user in Synology. But that's not how I want it.
>>>>
>>>> - Problem with all this is: no matter how I change these files, the next
>>>> time I would save something from the Synology UI, these files would be
>>>> overwritten
>>>>
>>>> Frustrating :(
>>>>
>>>> I would only suggest you to raise the problem with Synology support and
>>> convince them adding SSSD build and use it. SSSD has nfsidmap module
>>> 'sss' that does the right job on mapping based on what SSSD knows about
>>> Kerberos principals and user mapping for the domain.
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> On 12 August 2015 at 13:33, Roberto Cornacchia <
>>>> roberto.cornacc...@gmail.com
>>>>
>>>> wrote:
>>>>>
>>>>>
>>>> Enabled verbose output for rpc.idmapd as well, and now I see:
>>>>
>>>>>
>>>>> nfsidmap[5034]: nss_getpwnam: name 'test1_l@localdomain' does not map
>>>>> into domain 'hq.spinque.com'
>>>>>
>>>>>
>>>>> On 12 August 20

Re: [Freeipa-users] Kerberized NFS with Synology NAS

[Roberto Cornacchia]

I had Synology support inspect my configuration.

They said that the authorization for the mapping looks for attribute
"GSSAuthName" in LDAP, but doesn't find it. Therefore, they fall back to
mapping it to nobody.

Does this make sense to you? Is it true that GSSAuthName attribute isn't
there?



On 13 August 2015 at 16:34, Alexander Bokovoy  wrote:

> On Thu, 13 Aug 2015, Roberto Cornacchia wrote:
>
>> After some more investigation, I feel the problem I described can be
>> considered off topic, sorry about that. Initially I had the impression it
>> could have been more freeIPA-related.
>> It is sometimes difficult to tell whether the issue would show up
>> regardless of using freeIPA or not.
>>
>> Should anyone be curious, these are my findings about using a Synology
>> disk
>> station for NFSv4+krb5 exports in my freeIPA domain:
>>
>> - Still no idea why I see all those "Unspecified GSS failure" from
>> gssproxy
>> on the client side. Google tells me that many before me have wondered
>> about
>> it. Has anyone a clue?
>>
>> - The NFS4+krb5 mounting works, but what I ran into is the "nobody" issue.
>> NFSv4 relies on idmapd to map users correctly, but this goes wrong, hence
>> the "nobody" issue
>>
>> - One first problem is that I had not set the domain. My bad. Fixed and
>> got
>> one step further.
>>in idmapd.conf: Domain = hq.spinque.com
>>
>> - The second problem is that idmapd.conf in my synology says:
>>Method=nsswitch
>>GSS-Methods=static,synomap
>>
>>  No idea what "synomap" would be, but I guess GSS-Methods should be more
>> like "static,nsswitch,synomap"
>>  Indeed, everything works fine if I make static mappings for each LDAP
>> user to a local user in Synology. But that's not how I want it.
>>
>> - Problem with all this is: no matter how I change these files, the next
>> time I would save something from the Synology UI, these files would be
>> overwritten
>>
>> Frustrating :(
>>
> I would only suggest you to raise the problem with Synology support and
> convince them adding SSSD build and use it. SSSD has nfsidmap module
> 'sss' that does the right job on mapping based on what SSSD knows about
> Kerberos principals and user mapping for the domain.
>
>
>
>
>
>>
>>
>> On 12 August 2015 at 13:33, Roberto Cornacchia <
>> roberto.cornacc...@gmail.com
>>
>>> wrote:
>>>
>>
>> Enabled verbose output for rpc.idmapd as well, and now I see:
>>>
>>> nfsidmap[5034]: nss_getpwnam: name 'test1_l@localdomain' does not map
>>> into domain 'hq.spinque.com'
>>>
>>>
>>> On 12 August 2015 at 12:28, Roberto Cornacchia <
>>> roberto.cornacc...@gmail.com> wrote:
>>>
>>> I have used
>>>>
>>>> RPCGSSDARGS="-vvv"
>>>> RPCSVCGSSDARGS="-vvv"
>>>>
>>>> in /etc/sysconfig/nfs , as suggested in
>>>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html
>>>>
>>>> In the excerpt below, taken during the mount, meson is the client,
>>>> spinque03 is the nfs server (synology).
>>>>
>>>> It still doesn't tell me much, perhaps I'm missing something?
>>>>
>>>>
>>>> rpc.gssd[838]: handling gssd upcall (nfs/clnt19)
>>>> rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=0
>>>> enctypes=18,17,16,23,3,1,2 '
>>>> rpc.gssd[3328]: handling krb5 upcall (nfs/clnt19)
>>>> rpc.gssd[3328]: process_krb5_upcall: service is ''
>>>> rpc.gssd[3328]: Full hostname for 'spinque03.hq.spinque.com' is '
>>>> spinque03.hq.spinque.com'
>>>> rpc.gssd[3328]: Full hostname for 'meson.hq.spinque.com' is '
>>>> meson.hq.spinque.com'
>>>> rpc.gssd[3328]: No key table entry found for MESON$@HQ.SPINQUE.COM
>>>> while
>>>> getting keytab entry for 'MESON$@HQ.SPINQUE.COM'
>>>> rpc.gssd[3328]: No key table entry found for root/
>>>> meson.hq.spinque@hq.spinque.com while getting keytab entry for
>>>> 'root/
>>>> meson.hq.spinque@hq.spinque.com'
>>>> rpc.gssd[3328]: No key table entry found for nfs/
>>>> meson.hq.spinque@hq.spinque.com while getting keytab entry for
>>>> 'nfs/
>

Re: [Freeipa-users] Kerberized NFS with Synology NAS

[Roberto Cornacchia]

After some more investigation, I feel the problem I described can be
considered off topic, sorry about that. Initially I had the impression it
could have been more freeIPA-related.
It is sometimes difficult to tell whether the issue would show up
regardless of using freeIPA or not.

Should anyone be curious, these are my findings about using a Synology disk
station for NFSv4+krb5 exports in my freeIPA domain:

- Still no idea why I see all those "Unspecified GSS failure" from gssproxy
on the client side. Google tells me that many before me have wondered about
it. Has anyone a clue?

- The NFS4+krb5 mounting works, but what I ran into is the "nobody" issue.
NFSv4 relies on idmapd to map users correctly, but this goes wrong, hence
the "nobody" issue

- One first problem is that I had not set the domain. My bad. Fixed and got
one step further.
in idmapd.conf: Domain = hq.spinque.com

- The second problem is that idmapd.conf in my synology says:
Method=nsswitch
GSS-Methods=static,synomap

  No idea what "synomap" would be, but I guess GSS-Methods should be more
like "static,nsswitch,synomap"
  Indeed, everything works fine if I make static mappings for each LDAP
user to a local user in Synology. But that's not how I want it.

- Problem with all this is: no matter how I change these files, the next
time I would save something from the Synology UI, these files would be
overwritten

Frustrating :(



On 12 August 2015 at 13:33, Roberto Cornacchia  wrote:

> Enabled verbose output for rpc.idmapd as well, and now I see:
>
> nfsidmap[5034]: nss_getpwnam: name 'test1_l@localdomain' does not map
> into domain 'hq.spinque.com'
>
>
> On 12 August 2015 at 12:28, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>> I have used
>>
>> RPCGSSDARGS="-vvv"
>> RPCSVCGSSDARGS="-vvv"
>>
>> in /etc/sysconfig/nfs , as suggested in 
>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html
>>
>> In the excerpt below, taken during the mount, meson is the client, spinque03 
>> is the nfs server (synology).
>>
>> It still doesn't tell me much, perhaps I'm missing something?
>>
>>
>> rpc.gssd[838]: handling gssd upcall (nfs/clnt19)
>> rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=0
>> enctypes=18,17,16,23,3,1,2 '
>> rpc.gssd[3328]: handling krb5 upcall (nfs/clnt19)
>> rpc.gssd[3328]: process_krb5_upcall: service is ''
>> rpc.gssd[3328]: Full hostname for 'spinque03.hq.spinque.com' is '
>> spinque03.hq.spinque.com'
>> rpc.gssd[3328]: Full hostname for 'meson.hq.spinque.com' is '
>> meson.hq.spinque.com'
>> rpc.gssd[3328]: No key table entry found for MESON$@HQ.SPINQUE.COM while
>> getting keytab entry for 'MESON$@HQ.SPINQUE.COM'
>> rpc.gssd[3328]: No key table entry found for root/
>> meson.hq.spinque@hq.spinque.com while getting keytab entry for 'root/
>> meson.hq.spinque@hq.spinque.com'
>> rpc.gssd[3328]: No key table entry found for nfs/
>> meson.hq.spinque@hq.spinque.com while getting keytab entry for 'nfs/
>> meson.hq.spinque@hq.spinque.com'
>> rpc.gssd[3328]: Success getting keytab entry for 'host/
>> meson.hq.spinque@hq.spinque.com'
>> rpc.gssd[3328]: Successfully obtained machine credentials for principal
>> 'host/meson.hq.spinque@hq.spinque.com' stored in ccache 'FILE:/tmp/
>> krb5ccmachine_HQ.SPINQUE.COM'
>> rpc.gssd[3328]: INFO: Credentials in CC 'FILE:/tmp/
>> krb5ccmachine_HQ.SPINQUE.COM' are good until 1439461246
>> rpc.gssd[3328]: using FILE:/tmp/krb5ccmachine_HQ.SPINQUE.COM as
>> credentials cache for machine creds
>> rpc.gssd[3328]: using environment variable to select krb5 ccache
>> FILE:/tmp/krb5ccmachine_HQ.SPINQUE.COM
>> gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
>> Minor code may provide more information, No credentials cache found
>> gssproxy[798]: gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified
>> GSS failure.  Minor code may provide more information, No credentials cache
>> found
>> rpc.gssd[3328]: creating tcp client for server spinque03.hq.spinque.com
>> rpc.gssd[3328]: DEBUG: port already set to 2049
>> rpc.gssd[3328]: creating context with server n...@spinque03.hq.spinque.com
>> rpc.gssd[3328]: DEBUG: serialize_krb5_ctx: lucid version!
>> rpc.gssd[3328]: prepare_krb5_rfc4121_buffer: protocol 1
>> rpc.gssd[3328]: prepare_krb5_rfc4121_buffer: serializing key with enctype
>> 18 and size 32

Re: [Freeipa-users] Kerberized NFS with Synology NAS

[Roberto Cornacchia]

I have used

RPCGSSDARGS="-vvv"
RPCSVCGSSDARGS="-vvv"

in /etc/sysconfig/nfs , as suggested in
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html

In the excerpt below, taken during the mount, meson is the client,
spinque03 is the nfs server (synology).

It still doesn't tell me much, perhaps I'm missing something?


rpc.gssd[838]: handling gssd upcall (nfs/clnt19)
rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=0
enctypes=18,17,16,23,3,1,2 '
rpc.gssd[3328]: handling krb5 upcall (nfs/clnt19)
rpc.gssd[3328]: process_krb5_upcall: service is ''
rpc.gssd[3328]: Full hostname for 'spinque03.hq.spinque.com' is '
spinque03.hq.spinque.com'
rpc.gssd[3328]: Full hostname for 'meson.hq.spinque.com' is '
meson.hq.spinque.com'
rpc.gssd[3328]: No key table entry found for MESON$@HQ.SPINQUE.COM while
getting keytab entry for 'MESON$@HQ.SPINQUE.COM'
rpc.gssd[3328]: No key table entry found for root/
meson.hq.spinque@hq.spinque.com while getting keytab entry for 'root/
meson.hq.spinque@hq.spinque.com'
rpc.gssd[3328]: No key table entry found for nfs/
meson.hq.spinque@hq.spinque.com while getting keytab entry for 'nfs/
meson.hq.spinque@hq.spinque.com'
rpc.gssd[3328]: Success getting keytab entry for 'host/
meson.hq.spinque@hq.spinque.com'
rpc.gssd[3328]: Successfully obtained machine credentials for principal
'host/meson.hq.spinque@hq.spinque.com' stored in ccache 'FILE:/tmp/
krb5ccmachine_HQ.SPINQUE.COM'
rpc.gssd[3328]: INFO: Credentials in CC 'FILE:/tmp/
krb5ccmachine_HQ.SPINQUE.COM' are good until 1439461246
rpc.gssd[3328]: using FILE:/tmp/krb5ccmachine_HQ.SPINQUE.COM as credentials
cache for machine creds
rpc.gssd[3328]: using environment variable to select krb5 ccache FILE:/tmp/
krb5ccmachine_HQ.SPINQUE.COM
gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
Minor code may provide more information, No credentials cache found
gssproxy[798]: gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified
GSS failure.  Minor code may provide more information, No credentials cache
found
rpc.gssd[3328]: creating tcp client for server spinque03.hq.spinque.com
rpc.gssd[3328]: DEBUG: port already set to 2049
rpc.gssd[3328]: creating context with server n...@spinque03.hq.spinque.com
rpc.gssd[3328]: DEBUG: serialize_krb5_ctx: lucid version!
rpc.gssd[3328]: prepare_krb5_rfc4121_buffer: protocol 1
rpc.gssd[3328]: prepare_krb5_rfc4121_buffer: serializing key with enctype
18 and size 32
rpc.gssd[3328]: doing downcall: lifetime_rec=86399 acceptor=
n...@spinque03.hq.spinque.com
rpc.gssd[838]: handling gssd upcall (nfs/clnt19)
rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=1005
enctypes=18,17,16,23,3,1,2 '
rpc.gssd[3337]: handling krb5 upcall (nfs/clnt19)
rpc.gssd[3337]: process_krb5_upcall: service is ''
gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
Minor code may provide more information, No credentials cache found
gssproxy[798]: gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified
GSS failure.  Minor code may provide more information, No credentials cache
found
rpc.gssd[3337]: creating tcp client for server spinque03.hq.spinque.com
rpc.gssd[3337]: DEBUG: port already set to 2049
rpc.gssd[3337]: creating context with server n...@spinque03.hq.spinque.com
rpc.gssd[3337]: DEBUG: serialize_krb5_ctx: lucid version!
rpc.gssd[3337]: prepare_krb5_rfc4121_buffer: protocol 1
rpc.gssd[3337]: prepare_krb5_rfc4121_buffer: serializing key with enctype
18 and size 32
rpc.gssd[3337]: doing downcall: lifetime_rec=85675 acceptor=
n...@spinque03.hq.spinque.com


On 12 August 2015 at 02:46, Roberto Cornacchia  wrote:

> Hi,
>
> I am trying to use a Synology NAS station in my FreeIPA domain to host
> automounted home directories (not created automatically for now).
>
> I got almost everything working, but I seem to have a problem with
> kerberized nfs.
>
> The NAS logs in the LDAP domain and seems happy with the kerberos
> principal that I uploaded.
>
>
>
> * If I use plain nfs4 without krb5
>
> - /etc/exports -
> /volume1/shared_homes
> 192.168.0.0/24(rw,async,no_wdelay,all_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)
>
> then I can mount it and use it (it even works with automount). But only
> using all_squash. Not useful:
>
>
> * If I use krb5
>
> - /etc/exports -
> /volume1/shared_homes
> 192.168.0.0/24(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=krb5,anonuid=1025,anongid=100)
>
> then I can kinit with an LDAP user, mount it with sec=krb5, but I get
> "nobody" as file owner.
>
> This is done from a FC22 client, perfectly enrolled in freeIPA.
>
> The client's log contains several of such errors:
>
> 

Re: [Freeipa-users] Kerberized NFS with Synology NAS

[Roberto Cornacchia]

Enabled verbose output for rpc.idmapd as well, and now I see:

nfsidmap[5034]: nss_getpwnam: name 'test1_l@localdomain' does not map into
domain 'hq.spinque.com'


On 12 August 2015 at 12:28, Roberto Cornacchia  wrote:

> I have used
>
> RPCGSSDARGS="-vvv"
> RPCSVCGSSDARGS="-vvv"
>
> in /etc/sysconfig/nfs , as suggested in 
> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Installing_the_IPA_Client_on_Linux.html
>
> In the excerpt below, taken during the mount, meson is the client, spinque03 
> is the nfs server (synology).
>
> It still doesn't tell me much, perhaps I'm missing something?
>
>
> rpc.gssd[838]: handling gssd upcall (nfs/clnt19)
> rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=0
> enctypes=18,17,16,23,3,1,2 '
> rpc.gssd[3328]: handling krb5 upcall (nfs/clnt19)
> rpc.gssd[3328]: process_krb5_upcall: service is ''
> rpc.gssd[3328]: Full hostname for 'spinque03.hq.spinque.com' is '
> spinque03.hq.spinque.com'
> rpc.gssd[3328]: Full hostname for 'meson.hq.spinque.com' is '
> meson.hq.spinque.com'
> rpc.gssd[3328]: No key table entry found for MESON$@HQ.SPINQUE.COM while
> getting keytab entry for 'MESON$@HQ.SPINQUE.COM'
> rpc.gssd[3328]: No key table entry found for root/
> meson.hq.spinque@hq.spinque.com while getting keytab entry for 'root/
> meson.hq.spinque@hq.spinque.com'
> rpc.gssd[3328]: No key table entry found for nfs/
> meson.hq.spinque@hq.spinque.com while getting keytab entry for 'nfs/
> meson.hq.spinque@hq.spinque.com'
> rpc.gssd[3328]: Success getting keytab entry for 'host/
> meson.hq.spinque@hq.spinque.com'
> rpc.gssd[3328]: Successfully obtained machine credentials for principal
> 'host/meson.hq.spinque@hq.spinque.com' stored in ccache 'FILE:/tmp/
> krb5ccmachine_HQ.SPINQUE.COM'
> rpc.gssd[3328]: INFO: Credentials in CC 'FILE:/tmp/
> krb5ccmachine_HQ.SPINQUE.COM' are good until 1439461246
> rpc.gssd[3328]: using FILE:/tmp/krb5ccmachine_HQ.SPINQUE.COM as
> credentials cache for machine creds
> rpc.gssd[3328]: using environment variable to select krb5 ccache FILE:/tmp/
> krb5ccmachine_HQ.SPINQUE.COM
> gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
> Minor code may provide more information, No credentials cache found
> gssproxy[798]: gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified
> GSS failure.  Minor code may provide more information, No credentials cache
> found
> rpc.gssd[3328]: creating tcp client for server spinque03.hq.spinque.com
> rpc.gssd[3328]: DEBUG: port already set to 2049
> rpc.gssd[3328]: creating context with server n...@spinque03.hq.spinque.com
> rpc.gssd[3328]: DEBUG: serialize_krb5_ctx: lucid version!
> rpc.gssd[3328]: prepare_krb5_rfc4121_buffer: protocol 1
> rpc.gssd[3328]: prepare_krb5_rfc4121_buffer: serializing key with enctype
> 18 and size 32
> rpc.gssd[3328]: doing downcall: lifetime_rec=86399 acceptor=
> n...@spinque03.hq.spinque.com
> rpc.gssd[838]: handling gssd upcall (nfs/clnt19)
> rpc.gssd[838]: handle_gssd_upcall: 'mech=krb5 uid=1005
> enctypes=18,17,16,23,3,1,2 '
> rpc.gssd[3337]: handling krb5 upcall (nfs/clnt19)
> rpc.gssd[3337]: process_krb5_upcall: service is ''
> gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
> Minor code may provide more information, No credentials cache found
> gssproxy[798]: gssproxy[809]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified
> GSS failure.  Minor code may provide more information, No credentials cache
> found
> rpc.gssd[3337]: creating tcp client for server spinque03.hq.spinque.com
> rpc.gssd[3337]: DEBUG: port already set to 2049
> rpc.gssd[3337]: creating context with server n...@spinque03.hq.spinque.com
> rpc.gssd[3337]: DEBUG: serialize_krb5_ctx: lucid version!
> rpc.gssd[3337]: prepare_krb5_rfc4121_buffer: protocol 1
> rpc.gssd[3337]: prepare_krb5_rfc4121_buffer: serializing key with enctype
> 18 and size 32
> rpc.gssd[3337]: doing downcall: lifetime_rec=85675 acceptor=
> n...@spinque03.hq.spinque.com
>
>
> On 12 August 2015 at 02:46, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>> Hi,
>>
>> I am trying to use a Synology NAS station in my FreeIPA domain to host
>> automounted home directories (not created automatically for now).
>>
>> I got almost everything working, but I seem to have a problem with
>> kerberized nfs.
>>
>> The NAS logs in the LDAP domain and seems happy with the kerberos
>> principal that I uploaded.
>>
>>
>>
>> * If I use plain nfs4 without krb5
&g

[Freeipa-users] Kerberized NFS with Synology NAS

[Roberto Cornacchia]

Hi,

I am trying to use a Synology NAS station in my FreeIPA domain to host
automounted home directories (not created automatically for now).

I got almost everything working, but I seem to have a problem with
kerberized nfs.

The NAS logs in the LDAP domain and seems happy with the kerberos principal
that I uploaded.



* If I use plain nfs4 without krb5

- /etc/exports -
/volume1/shared_homes
192.168.0.0/24(rw,async,no_wdelay,all_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

then I can mount it and use it (it even works with automount). But only
using all_squash. Not useful:


* If I use krb5

- /etc/exports -
/volume1/shared_homes
192.168.0.0/24(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=krb5,anonuid=1025,anongid=100)

then I can kinit with an LDAP user, mount it with sec=krb5, but I get
"nobody" as file owner.

This is done from a FC22 client, perfectly enrolled in freeIPA.

The client's log contains several of such errors:

gssproxy[807]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure.
Minor code may provide more information, No credentials cache found


Any tip to help me understand what the problem is?
Roberto
-- 
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] Setup of freeipa 4.1.3 failed

[Roberto Cornacchia]

Unfortunately I don't have the log anymore, as it was overwritten by the
following successful installation.
But the personal log I kept manually says (this was freeIPA 4.1.2):

...
Restarting the directory server
Restarting the KDC
Restarting the certificate server

CA did not start in 300.0s

It seems that Stash was already using port 8443.
Changed Stash configuration and (just to be sure) stopped both Jira and
Stash before attempting again

Ran
$ ipa-server-install --uninstall

and tried installation again.
Succeeded:




On 1 April 2015 at 16:17, Martin Kosek  wrote:

> Hmm, really? The port 8443 is already checked in FreeIPA 4.0.4 or later,
> based
> on this ticket:
>
> https://fedorahosted.org/freeipa/ticket/4564
>
> If your installation crashed because port 8443 was occupied, the fix 4564
> is
> either incomplete or non-functional and we should fix it.
>
> On 04/01/2015 01:38 PM, Roberto Cornacchia wrote:
> > I had this error during my first installation. It turned out the problem
> > was that port 8443 was already used by another process.
> >
> > Roberto
> >
> > On 31 March 2015 at 19:54, Markus Roth  wrote:
> >
> >> Hi all,
> >>
> >> I want setup freeipa 4.1.3 on a fresh installed fedora 21.
> >> The ipa-server-install shows the following output:
> >>
> >> configuring NTP daemon (ntpd)
> >>   [1/4]: stopping ntpd
> >>   [2/4]: writing configuration
> >>   [3/4]: configuring ntpd to start on boot
> >>   [4/4]: starting ntpd
> >> Done configuring NTP daemon (ntpd).
> >> Configuring directory server (dirsrv): Estimated time 1 minute
> >>   [1/38]: creating directory server user
> >>   [2/38]: creating directory server instance
> >>   [3/38]: adding default schema
> >>   [4/38]: enabling memberof plugin
> >>   [5/38]: enabling winsync plugin
> >>   [6/38]: configuring replication version plugin
> >>   [7/38]: enabling IPA enrollment plugin
> >>   [8/38]: enabling ldapi
> >>   [9/38]: configuring uniqueness plugin
> >>   [10/38]: configuring uuid plugin
> >>   [11/38]: configuring modrdn plugin
> >>   [12/38]: configuring DNS plugin
> >>   [13/38]: enabling entryUSN plugin
> >>   [14/38]: configuring lockout plugin
> >>   [15/38]: creating indices
> >>   [16/38]: enabling referential integrity plugin
> >>   [17/38]: configuring certmap.conf
> >>   [18/38]: configure autobind for root
> >>   [19/38]: configure new location for managed entries
> >>   [20/38]: configure dirsrv ccache
> >>   [21/38]: enable SASL mapping fallback
> >>   [22/38]: restarting directory server
> >>   [23/38]: adding default layout
> >>   [24/38]: adding delegation layout
> >>   [25/38]: creating container for managed entries
> >>   [26/38]: configuring user private groups
> >>   [27/38]: configuring netgroups from hostgroups
> >>   [28/38]: creating default Sudo bind user
> >>   [29/38]: creating default Auto Member layout
> >>   [30/38]: adding range check plugin
> >>   [31/38]: creating default HBAC rule allow_all
> >>   [32/38]: initializing group membership
> >>   [33/38]: adding master entry
> >>   [34/38]: configuring Posix uid/gid generation
> >>   [35/38]: adding replication acis
> >>   [36/38]: enabling compatibility plugin
> >>   [37/38]: tuning directory server
> >>   [38/38]: configuring directory to start on boot
> >> Done configuring directory server (dirsrv).
> >> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
> 30
> >> seconds
> >>   [1/27]: creating certificate server user
> >>   [2/27]: configuring certificate server instance
> >>   [3/27]: stopping certificate server instance to update CS.cfg
> >>   [4/27]: backing up CS.cfg
> >>   [5/27]: disabling nonces
> >>   [6/27]: set up CRL publishing
> >>   [7/27]: enable PKIX certificate path discovery and validation
> >>   [8/27]: starting certificate server instance
> >>   [error] RuntimeError: CA did not start in 300.0s
> >> CA did not start in 300.0s
> >>
> >> The ipa server install log shows this:
> >>
> >> 2015-03-31T17:39:35Z DEBUG The CA status is: check interrupted
> >> 2015-03-31T17:39:35Z DEBUG Waiting for CA to start...
> >> 2015-03-31T17:39:36Z DEBUG Traceback (most recent call last):
> >>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> >> line
> >> 382, in start_creat

Re: [Freeipa-users] Setup of freeipa 4.1.3 failed

[Roberto Cornacchia]

I had this error during my first installation. It turned out the problem
was that port 8443 was already used by another process.

Roberto

On 31 March 2015 at 19:54, Markus Roth  wrote:

> Hi all,
>
> I want setup freeipa 4.1.3 on a fresh installed fedora 21.
> The ipa-server-install shows the following output:
>
> configuring NTP daemon (ntpd)
>   [1/4]: stopping ntpd
>   [2/4]: writing configuration
>   [3/4]: configuring ntpd to start on boot
>   [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv): Estimated time 1 minute
>   [1/38]: creating directory server user
>   [2/38]: creating directory server instance
>   [3/38]: adding default schema
>   [4/38]: enabling memberof plugin
>   [5/38]: enabling winsync plugin
>   [6/38]: configuring replication version plugin
>   [7/38]: enabling IPA enrollment plugin
>   [8/38]: enabling ldapi
>   [9/38]: configuring uniqueness plugin
>   [10/38]: configuring uuid plugin
>   [11/38]: configuring modrdn plugin
>   [12/38]: configuring DNS plugin
>   [13/38]: enabling entryUSN plugin
>   [14/38]: configuring lockout plugin
>   [15/38]: creating indices
>   [16/38]: enabling referential integrity plugin
>   [17/38]: configuring certmap.conf
>   [18/38]: configure autobind for root
>   [19/38]: configure new location for managed entries
>   [20/38]: configure dirsrv ccache
>   [21/38]: enable SASL mapping fallback
>   [22/38]: restarting directory server
>   [23/38]: adding default layout
>   [24/38]: adding delegation layout
>   [25/38]: creating container for managed entries
>   [26/38]: configuring user private groups
>   [27/38]: configuring netgroups from hostgroups
>   [28/38]: creating default Sudo bind user
>   [29/38]: creating default Auto Member layout
>   [30/38]: adding range check plugin
>   [31/38]: creating default HBAC rule allow_all
>   [32/38]: initializing group membership
>   [33/38]: adding master entry
>   [34/38]: configuring Posix uid/gid generation
>   [35/38]: adding replication acis
>   [36/38]: enabling compatibility plugin
>   [37/38]: tuning directory server
>   [38/38]: configuring directory to start on boot
> Done configuring directory server (dirsrv).
> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30
> seconds
>   [1/27]: creating certificate server user
>   [2/27]: configuring certificate server instance
>   [3/27]: stopping certificate server instance to update CS.cfg
>   [4/27]: backing up CS.cfg
>   [5/27]: disabling nonces
>   [6/27]: set up CRL publishing
>   [7/27]: enable PKIX certificate path discovery and validation
>   [8/27]: starting certificate server instance
>   [error] RuntimeError: CA did not start in 300.0s
> CA did not start in 300.0s
>
> The ipa server install log shows this:
>
> 2015-03-31T17:39:35Z DEBUG The CA status is: check interrupted
> 2015-03-31T17:39:35Z DEBUG Waiting for CA to start...
> 2015-03-31T17:39:36Z DEBUG Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line
> 382, in start_creation
> run_step(full_msg, method)
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line
> 372, in run_step
> method()
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
> line 526, in __start
> self.start()
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line
> 279, in start
> self.service.start(instance_name, capture_output=capture_output,
> wait=wait)
>   File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
> line
> 229, in start
> self.wait_until_running()
>   File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py",
> line
> 223, in wait_until_running
> raise RuntimeError('CA did not start in %ss' % timeout)
> RuntimeError: CA did not start in 300.0s
>
> 2015-03-31T17:39:36Z DEBUG   [error] RuntimeError: CA did not start in
> 300.0s
> 2015-03-31T17:39:36Z DEBUG   File "/usr/lib/python2.7/site-
> packages/ipaserver/install/installutils.py", line 642, in run_script
> return_value = main_function()
>
>   File "/usr/sbin/ipa-server-install", line 1183, in main
> ca_signing_algorithm=options.ca_signing_algorithm)
>
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
> line 520, in configure_instance
> self.start_creation(runtime=210)
>
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line
> 382, in start_creation
> run_step(full_msg, method)
>
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line
> 372, in run_step
> method()
>
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py",
> line 526, in __start
> self.start()
>
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line
> 279, in start
> self.service.start(instance_name, capture_output=capture_output,
> wait=wait)
>
>   File "/usr/lib/python2.7/s

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

On 24 March 2015 at 14:49, Dmitri Pal  wrote:

>  On 03/24/2015 09:43 AM, Roberto Cornacchia wrote:
>
> Hi there,
>
>  All the issues I reported in this long thread are SOLVED.
>
>
> Thanks for closing the loop.
>
>  For completeness, I'm posting here the conclusions.
>
>  ipa-client-install did enroll the client but failed in several points:
>
>  $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
> [...]
> Synchronizing time with KDC...
>  Unable to sync time with IPA NTP server, assuming the time is in sync.
> Please check that 123 UDP port is opened.
> [...]
> Failed to update DNS records.
> [...]
> Could not update DNS SSHFP records.
>  [...]
> Unable to find 'admin' user with 'getent passwd ad...@hq.example.com'!
>  Unable to reliably detect configuration. Check NSS setup manually.
> [...]
> Client configuration complete.
>
>  There were two distinct problems:
>
>  1) NTP sync failed because despite using --force-ntp, chronyd wasn't
> stopped beforehand. Stopping it manually solved the issue. I believe
> ipa-client-install stopping chronyd was the intended behaviour, in which
> case this is perhaps a bug. If it needs to be stopped manually, then it
> should be documented clearly.
> The failed NTP sync caused Kerberos to fail, which explains "Unable to
> find 'admin' user with 'getent passwd ad...@hq.example.com'".
>
>
> We should probably file a ticket about this. I am just not sure what
> exactly it should be.
>
>
>
IMHO, the "assuming the time is in sync" bit is dangerous. The client and
the server were already quite in sync (both automatically synced with a
remote time server) , but apparently not enough. Being time sync so central
in the infrastructure, I would probably want to abort the installation if
no sync can be performed successfully.



>
>  2) DNS update failed because for some obscure reason I forgot to open
> port 53/tcp on the server's firewall. Only 53/udp was open. This fooled me,
> because with 53/udp open, the DNS was almost completely functional.
> However, updates also require 53/tcp.
>
>
>  All in all, it was a full 2day digging and debugging. Bright side is, I
> learned a lot.
>
>  A sincere thank you for the many useful answers I received!
> Best,
> Roberto
>
>
> On 23 March 2015 at 10:07, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>>  Dmitri, Rob, Jakub,
>>
>>  I found at least one of the major problems: chronyd.
>>
>>  This is what I get when I use ipa-client-install on a plain FC21
>> machine, *without* using --force-ntpd
>>
>>  WARNING: ntpd time&date synchronization service will not be configured
>> as
>> conflicting service (chronyd) is enabled
>> Use --force-ntpd option to disable it and force configuration of ntpd
>>
>>
>>  Good, then I abort and run it again with  --force-ntpd:
>>
>>   Synchronizing time with KDC...
>>  Unable to sync time with IPA NTP server, assuming the time is in sync.
>> Please check that 123 UDP port is opened.
>>
>>
>>  Perhaps I misinterpreted the meaning of --force-ntpd. I had assumed it
>> would take care of stopping and disabling chronyd. But it doesn't. That's
>> why I get the error above.
>>
>>  If I first stop chronyd manually and run the installation again, then
>> it does synchronise with NTP.
>> This was apparently the cause of "id admin" not working (kerberos failing
>> without proper NTP sync?)
>> Now the basic functionalities are all OK.
>> Also, chronyd is disabled and ntpd is enabled after installation - good.
>>
>>  My nsswitch.conf now looks like this:
>>
>>  passwd: files sss
>> shadow: files sss
>> group:  files sss
>>  hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
>>  bootparams: nisplus [NOTFOUND=return] files
>>  ethers: files
>>  netmasks:   files
>> networks:   files
>> protocols:  files
>> rpc:files
>>  services:   files sss
>> netgroup:   files sss
>>  publickey:  nisplus
>>  automount:  files sss
>>  aliases:files nisplus
>> sudoers: files sss
>>
>>
>>
>>  I am left with 2 issues:
>>
>>  1) Is the above expected? Do I have to stop chronyd manually? Or is it
>> a bug?
>> 2) DNS update still does not work
>>
>>
>>  The latest installation log:
>>
>>
>>  $ systemctl stop chronyd
>>  $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
>>  Discovery was successf

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

Hi there,

All the issues I reported in this long thread are SOLVED.
For completeness, I'm posting here the conclusions.

ipa-client-install did enroll the client but failed in several points:

$ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
[...]
Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync.
Please check that 123 UDP port is opened.
[...]
Failed to update DNS records.
[...]
Could not update DNS SSHFP records.
[...]
Unable to find 'admin' user with 'getent passwd ad...@hq.example.com'!
Unable to reliably detect configuration. Check NSS setup manually.
[...]
Client configuration complete.

There were two distinct problems:

1) NTP sync failed because despite using --force-ntp, chronyd wasn't
stopped beforehand. Stopping it manually solved the issue. I believe
ipa-client-install stopping chronyd was the intended behaviour, in which
case this is perhaps a bug. If it needs to be stopped manually, then it
should be documented clearly.
The failed NTP sync caused Kerberos to fail, which explains "Unable to find
'admin' user with 'getent passwd ad...@hq.example.com'".

2) DNS update failed because for some obscure reason I forgot to open port
53/tcp on the server's firewall. Only 53/udp was open. This fooled me,
because with 53/udp open, the DNS was almost completely functional.
However, updates also require 53/tcp.


All in all, it was a full 2day digging and debugging. Bright side is, I
learned a lot.

A sincere thank you for the many useful answers I received!
Best,
Roberto


On 23 March 2015 at 10:07, Roberto Cornacchia 
wrote:

> Dmitri, Rob, Jakub,
>
> I found at least one of the major problems: chronyd.
>
> This is what I get when I use ipa-client-install on a plain FC21 machine,
> *without* using --force-ntpd
>
> WARNING: ntpd time&date synchronization service will not be configured as
> conflicting service (chronyd) is enabled
> Use --force-ntpd option to disable it and force configuration of ntpd
>
>
> Good, then I abort and run it again with  --force-ntpd:
>
> Synchronizing time with KDC...
> Unable to sync time with IPA NTP server, assuming the time is in sync.
> Please check that 123 UDP port is opened.
>
>
> Perhaps I misinterpreted the meaning of --force-ntpd. I had assumed it
> would take care of stopping and disabling chronyd. But it doesn't. That's
> why I get the error above.
>
> If I first stop chronyd manually and run the installation again, then it
> does synchronise with NTP.
> This was apparently the cause of "id admin" not working (kerberos failing
> without proper NTP sync?)
> Now the basic functionalities are all OK.
> Also, chronyd is disabled and ntpd is enabled after installation - good.
>
> My nsswitch.conf now looks like this:
>
> passwd: files sss
> shadow: files sss
> group:  files sss
> hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
> bootparams: nisplus [NOTFOUND=return] files
> ethers: files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:files
> services:   files sss
> netgroup:   files sss
> publickey:  nisplus
> automount:  files sss
> aliases:files nisplus
> sudoers: files sss
>
>
>
> I am left with 2 issues:
>
> 1) Is the above expected? Do I have to stop chronyd manually? Or is it a
> bug?
> 2) DNS update still does not work
>
>
> The latest installation log:
>
>
> $ systemctl stop chronyd
> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
> Discovery was successful!
> Hostname: meson.hq.example.com
> Realm: HQ.EXAMPLE.COM
> DNS Domain: hq.example.com
> IPA Server: ipa.hq.example.com
> BaseDN: dc=hq,dc=example,dc=com
>
> Continue to configure the system with these values? [no]: yes
> Synchronizing time with KDC...
> User authorized to enroll computers: User authorized to enroll computers:
> admin
> Password for ad...@hq.example.com:
> Successfully retrieved CA cert
> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
> Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
> Valid From:  Mon Mar 16 18:44:35 2015 UTC
> Valid Until: Fri Mar 16 18:44:35 2035 UTC
>
> Enrolled in IPA realm HQ.EXAMPLE.COM
> Created /etc/ipa/default.conf
> New SSSD config will be created
> Configured sudoers in /etc/nsswitch.conf
> Configured /etc/sssd/sssd.conf
> Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
> trying https://ipa.hq.example.com/ipa/json
> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
> Forwarding 'ca_is_enabled' to json server 'https://ipa.hq.example.com
> /ipa/json'
> Systemwide CA 

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

Thank you, dump sent privately

On 23 March 2015 at 13:33, Petr Spacek  wrote:

> On 23.3.2015 12:33, Roberto Cornacchia wrote:
> > OK, thanks.
> > That would be "Dynamic updates", right? Then it is enabled.
> >
> > $ ipa dnszone-show --all
> > Zone name: hq.example.com
> >   dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com
> >   Zone name: hq.example.com.
> >   Active zone: TRUE
> >   Authoritative nameserver: ipa.hq.example.com.
> >   Administrator e-mail address: hostmaster.hq.example.com.
> >   SOA serial: 1427108043
> >   SOA refresh: 3600
> >   SOA retry: 900
> >   SOA expire: 1209600
> >   SOA minimum: 3600
> >   BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant
> HQ.EXAMPLE.COM
> > krb5-self * ; grant HQ.EXAMPLE.COM krb5-self * SSHFP;
> >   Dynamic update: TRUE
>
> This is correct (but it should not affect SOA query anyway).
>
> Could you share named logs on debug level 10 with us? It would be even
> better
> is you could provide us tcpdump with transactions in question.
>
> On the client (before you start installation) please:
> 1) Execute command $ tcpdump -i any -w /tmp/dns.pcap 'port 53'
> 2) Run ipa-client-install
> 3) Kill the tcpdump: $ pkill tcpdump
> 4) Send us the file.
>
> Feel free to send the files to me (pspa...@redhat.com) and Martin^2
> (mba...@redhat.com) privately if you do not want to make them public.
>
> Have a nice day!
>
> Petr^2 Spacek
>
> >   Allow query: any;
> >   Allow transfer: none;
> >   Allow PTR sync: FALSE
> >   nsrecord: ipa.hq.example.com.
> >   objectclass: idnszone, top, idnsrecord
> >
> >
> > On 23 March 2015 at 12:27, Martin Basti  wrote:
> >
> >>  On 23/03/15 12:19, Roberto Cornacchia wrote:
> >>
> >> BTW, shouldn't named.conf contain an "allow-update" statement? Mine
> >> doesn't. Or is this managed differently?
> >>
> >> It is not needed.
> >> bind-dyndb-ldap plugin overrides this configuration, you just need to
> >> enable updates in IPA zone setting.
> >>
> >> Martin
> >>
> >>
> >>
> >> On 23 March 2015 at 12:16, Roberto Cornacchia <
> >> roberto.cornacc...@gmail.com> wrote:
> >>
> >>>
> >>>
> >>> On 23 March 2015 at 10:35, Petr Spacek  wrote:
> >>>
> >>>> On 23.3.2015 10:21, Roberto Cornacchia wrote:
> >>>>> About the DNS update, this is what the debug log has to say:
> >>>>>
> >>>>> Found zone name: hq.example.com
> >>>>> The master is: ipa.hq.example.com
> >>>>> start_gssrequest
> >>>>> Found realm from ticket: HQ.EXAMPLE.COM
> >>>>> send_gssrequest
> >>>>> *; Communication with 192.168.0.72#53 failed: operation canceled*
> >>>>> *Reply from SOA query:*
> >>>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id:   4923
> >>>>> ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> >>>>> ;; QUESTION SECTION:
> >>>>> ;1835417091.sig-ipa.hq.example.com. ANY TKEY
> >>>>>
> >>>>> response to SOA query was unsuccessful
> >>>>
> >>>> - Please verify that 192.168.0.72 is the correct IP address of the
> >>>> FreeIPA server.
> >>>>
> >>>
> >>>  Positive
> >>>
> >>>
> >>>> - Please check named.logs on the server side to see if there are any
> >>>> complains
> >>>> about unsuccessful key negotiation with client.
> >>>>
> >>>>
> >>>  I raised named's log level to debug 10 and restarted
> >>> Ran ipa-client-install again.
> >>> The log shows many queries from the client, for A/AAA/SOA record types,
> >>> both about the server and the client. All approved, no problem.
> >>> The log does not seem to contain a single failure / rejection.
> >>>
> >>>  However:
> >>> 1) The client reports that response to SOA query was unsuccessful. The
> >>> server log does not say anything about this.
> >>> 2) The server log does not contain any update request
> >>>
> >>>
> >>>>> Notice that is is *different* from what I got before the chronyd
> >>>> change.
> >>>>> Before, there was not even a reply:
> >>>>>
> >>>>> Found zone name: hq.example.com
> >>>>> The master is: ipa.hq.example.com
> >>>>> start_gssrequest
> >>>>> Found realm from ticket: HQ.EXAMPLE.COM
> >>>>> send_gssrequest
> >>>>> *; Communication with 192.168.0.72#53 failed: operation canceled*
> >>>>> *could not reach any name server*
> >>>>
> >>>> Interesting, this should not be related to time synchronization in any
> >>>> way.
> >>>> DNS server simply did not return any answer.
> >>>>
> >>>> --
> >>>> Petr^2 Spacek
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

OK, thanks.
That would be "Dynamic updates", right? Then it is enabled.

$ ipa dnszone-show --all
Zone name: hq.example.com
  dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com
  Zone name: hq.example.com.
  Active zone: TRUE
  Authoritative nameserver: ipa.hq.example.com.
  Administrator e-mail address: hostmaster.hq.example.com.
  SOA serial: 1427108043
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM
krb5-self * ; grant HQ.EXAMPLE.COM krb5-self * SSHFP;
  Dynamic update: TRUE
  Allow query: any;
  Allow transfer: none;
  Allow PTR sync: FALSE
  nsrecord: ipa.hq.example.com.
  objectclass: idnszone, top, idnsrecord


On 23 March 2015 at 12:27, Martin Basti  wrote:

>  On 23/03/15 12:19, Roberto Cornacchia wrote:
>
> BTW, shouldn't named.conf contain an "allow-update" statement? Mine
> doesn't. Or is this managed differently?
>
> It is not needed.
> bind-dyndb-ldap plugin overrides this configuration, you just need to
> enable updates in IPA zone setting.
>
> Martin
>
>
>
> On 23 March 2015 at 12:16, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>>
>>
>> On 23 March 2015 at 10:35, Petr Spacek  wrote:
>>
>>> On 23.3.2015 10:21, Roberto Cornacchia wrote:
>>> > About the DNS update, this is what the debug log has to say:
>>> >
>>> > Found zone name: hq.example.com
>>> > The master is: ipa.hq.example.com
>>> > start_gssrequest
>>> > Found realm from ticket: HQ.EXAMPLE.COM
>>> > send_gssrequest
>>> > *; Communication with 192.168.0.72#53 failed: operation canceled*
>>> > *Reply from SOA query:*
>>> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id:   4923
>>> > ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>>> > ;; QUESTION SECTION:
>>> > ;1835417091.sig-ipa.hq.example.com. ANY TKEY
>>> >
>>> > response to SOA query was unsuccessful
>>>
>>> - Please verify that 192.168.0.72 is the correct IP address of the
>>> FreeIPA server.
>>>
>>
>>  Positive
>>
>>
>>> - Please check named.logs on the server side to see if there are any
>>> complains
>>> about unsuccessful key negotiation with client.
>>>
>>>
>>  I raised named's log level to debug 10 and restarted
>> Ran ipa-client-install again.
>> The log shows many queries from the client, for A/AAA/SOA record types,
>> both about the server and the client. All approved, no problem.
>> The log does not seem to contain a single failure / rejection.
>>
>>  However:
>> 1) The client reports that response to SOA query was unsuccessful. The
>> server log does not say anything about this.
>> 2) The server log does not contain any update request
>>
>>
>>> > Notice that is is *different* from what I got before the chronyd
>>> change.
>>> > Before, there was not even a reply:
>>> >
>>> > Found zone name: hq.example.com
>>> > The master is: ipa.hq.example.com
>>> > start_gssrequest
>>> > Found realm from ticket: HQ.EXAMPLE.COM
>>> > send_gssrequest
>>> > *; Communication with 192.168.0.72#53 failed: operation canceled*
>>> > *could not reach any name server*
>>>
>>> Interesting, this should not be related to time synchronization in any
>>> way.
>>> DNS server simply did not return any answer.
>>>
>>> --
>>> Petr^2 Spacek
>>>
>>> --
>>> Manage your subscription for the Freeipa-users mailing list:
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> Go to http://freeipa.org for more info on the project
>>>
>>
>>
>
>
>
>
> --
> Martin Basti
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

BTW, shouldn't named.conf contain an "allow-update" statement? Mine
doesn't. Or is this managed differently?


On 23 March 2015 at 12:16, Roberto Cornacchia 
wrote:

>
>
> On 23 March 2015 at 10:35, Petr Spacek  wrote:
>
>> On 23.3.2015 10:21, Roberto Cornacchia wrote:
>> > About the DNS update, this is what the debug log has to say:
>> >
>> > Found zone name: hq.example.com
>> > The master is: ipa.hq.example.com
>> > start_gssrequest
>> > Found realm from ticket: HQ.EXAMPLE.COM
>> > send_gssrequest
>> > *; Communication with 192.168.0.72#53 failed: operation canceled*
>> > *Reply from SOA query:*
>> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id:   4923
>> > ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>> > ;; QUESTION SECTION:
>> > ;1835417091.sig-ipa.hq.example.com. ANY TKEY
>> >
>> > response to SOA query was unsuccessful
>>
>> - Please verify that 192.168.0.72 is the correct IP address of the
>> FreeIPA server.
>>
>
> Positive
>
>
>> - Please check named.logs on the server side to see if there are any
>> complains
>> about unsuccessful key negotiation with client.
>>
>>
> I raised named's log level to debug 10 and restarted
> Ran ipa-client-install again.
> The log shows many queries from the client, for A/AAA/SOA record types,
> both about the server and the client. All approved, no problem.
> The log does not seem to contain a single failure / rejection.
>
> However:
> 1) The client reports that response to SOA query was unsuccessful. The
> server log does not say anything about this.
> 2) The server log does not contain any update request
>
>
>> > Notice that is is *different* from what I got before the chronyd change.
>> > Before, there was not even a reply:
>> >
>> > Found zone name: hq.example.com
>> > The master is: ipa.hq.example.com
>> > start_gssrequest
>> > Found realm from ticket: HQ.EXAMPLE.COM
>> > send_gssrequest
>> > *; Communication with 192.168.0.72#53 failed: operation canceled*
>> > *could not reach any name server*
>>
>> Interesting, this should not be related to time synchronization in any
>> way.
>> DNS server simply did not return any answer.
>>
>> --
>> Petr^2 Spacek
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

On 23 March 2015 at 10:35, Petr Spacek  wrote:

> On 23.3.2015 10:21, Roberto Cornacchia wrote:
> > About the DNS update, this is what the debug log has to say:
> >
> > Found zone name: hq.example.com
> > The master is: ipa.hq.example.com
> > start_gssrequest
> > Found realm from ticket: HQ.EXAMPLE.COM
> > send_gssrequest
> > *; Communication with 192.168.0.72#53 failed: operation canceled*
> > *Reply from SOA query:*
> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id:   4923
> > ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> > ;; QUESTION SECTION:
> > ;1835417091.sig-ipa.hq.example.com. ANY TKEY
> >
> > response to SOA query was unsuccessful
>
> - Please verify that 192.168.0.72 is the correct IP address of the FreeIPA
> server.
>

Positive


> - Please check named.logs on the server side to see if there are any
> complains
> about unsuccessful key negotiation with client.
>
>
I raised named's log level to debug 10 and restarted
Ran ipa-client-install again.
The log shows many queries from the client, for A/AAA/SOA record types,
both about the server and the client. All approved, no problem.
The log does not seem to contain a single failure / rejection.

However:
1) The client reports that response to SOA query was unsuccessful. The
server log does not say anything about this.
2) The server log does not contain any update request


> > Notice that is is *different* from what I got before the chronyd change.
> > Before, there was not even a reply:
> >
> > Found zone name: hq.example.com
> > The master is: ipa.hq.example.com
> > start_gssrequest
> > Found realm from ticket: HQ.EXAMPLE.COM
> > send_gssrequest
> > *; Communication with 192.168.0.72#53 failed: operation canceled*
> > *could not reach any name server*
>
> Interesting, this should not be related to time synchronization in any way.
> DNS server simply did not return any answer.
>
> --
> Petr^2 Spacek
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

About the DNS update, this is what the debug log has to say:

Found zone name: hq.example.com
The master is: ipa.hq.example.com
start_gssrequest
Found realm from ticket: HQ.EXAMPLE.COM
send_gssrequest
*; Communication with 192.168.0.72#53 failed: operation canceled*
*Reply from SOA query:*
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id:   4923
;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;1835417091.sig-ipa.hq.example.com. ANY TKEY

response to SOA query was unsuccessful



Notice that is is *different* from what I got before the chronyd change.
Before, there was not even a reply:

Found zone name: hq.example.com
The master is: ipa.hq.example.com
start_gssrequest
Found realm from ticket: HQ.EXAMPLE.COM
send_gssrequest
*; Communication with 192.168.0.72#53 failed: operation canceled*
*could not reach any name server*




On 23 March 2015 at 10:07, Roberto Cornacchia 
wrote:

> Dmitri, Rob, Jakub,
>
> I found at least one of the major problems: chronyd.
>
> This is what I get when I use ipa-client-install on a plain FC21 machine,
> *without* using --force-ntpd
>
> WARNING: ntpd time&date synchronization service will not be configured as
> conflicting service (chronyd) is enabled
> Use --force-ntpd option to disable it and force configuration of ntpd
>
>
> Good, then I abort and run it again with  --force-ntpd:
>
> Synchronizing time with KDC...
> Unable to sync time with IPA NTP server, assuming the time is in sync.
> Please check that 123 UDP port is opened.
>
>
> Perhaps I misinterpreted the meaning of --force-ntpd. I had assumed it
> would take care of stopping and disabling chronyd. But it doesn't. That's
> why I get the error above.
>
> If I first stop chronyd manually and run the installation again, then it
> does synchronise with NTP.
> This was apparently the cause of "id admin" not working (kerberos failing
> without proper NTP sync?)
> Now the basic functionalities are all OK.
> Also, chronyd is disabled and ntpd is enabled after installation - good.
>
> My nsswitch.conf now looks like this:
>
> passwd: files sss
> shadow: files sss
> group:  files sss
> hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
> bootparams: nisplus [NOTFOUND=return] files
> ethers: files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:files
> services:   files sss
> netgroup:   files sss
> publickey:  nisplus
> automount:  files sss
> aliases:files nisplus
> sudoers: files sss
>
>
>
> I am left with 2 issues:
>
> 1) Is the above expected? Do I have to stop chronyd manually? Or is it a
> bug?
> 2) DNS update still does not work
>
>
> The latest installation log:
>
>
> $ systemctl stop chronyd
> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
> Discovery was successful!
> Hostname: meson.hq.example.com
> Realm: HQ.EXAMPLE.COM
> DNS Domain: hq.example.com
> IPA Server: ipa.hq.example.com
> BaseDN: dc=hq,dc=example,dc=com
>
> Continue to configure the system with these values? [no]: yes
> Synchronizing time with KDC...
> User authorized to enroll computers: User authorized to enroll computers:
> admin
> Password for ad...@hq.example.com:
> Successfully retrieved CA cert
> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
> Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
> Valid From:  Mon Mar 16 18:44:35 2015 UTC
> Valid Until: Fri Mar 16 18:44:35 2035 UTC
>
> Enrolled in IPA realm HQ.EXAMPLE.COM
> Created /etc/ipa/default.conf
> New SSSD config will be created
> Configured sudoers in /etc/nsswitch.conf
> Configured /etc/sssd/sssd.conf
> Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
> trying https://ipa.hq.example.com/ipa/json
> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
> Forwarding 'ca_is_enabled' to json server 'https://ipa.hq.example.com
> /ipa/json'
> Systemwide CA database updated.
> Added CA certificates to the default NSS database.
> Hostname (meson.hq.example.com) not found in DNS
> *Failed to update DNS records.*
> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
> Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json'
> *Could not update DNS SSHFP records.*
> SSSD enabled
> Configured /etc/openldap/ldap.conf
> NTP enabled
> Configured /etc/ssh/ssh_config
> Configured /etc/ssh/sshd_config
> Configuring hq.example.com as NIS domain.
> Client configuration complete.
&g

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

Dmitri, Rob, Jakub,

I found at least one of the major problems: chronyd.

This is what I get when I use ipa-client-install on a plain FC21 machine,
*without* using --force-ntpd

WARNING: ntpd time&date synchronization service will not be configured as
conflicting service (chronyd) is enabled
Use --force-ntpd option to disable it and force configuration of ntpd


Good, then I abort and run it again with  --force-ntpd:

Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync.
Please check that 123 UDP port is opened.


Perhaps I misinterpreted the meaning of --force-ntpd. I had assumed it
would take care of stopping and disabling chronyd. But it doesn't. That's
why I get the error above.

If I first stop chronyd manually and run the installation again, then it
does synchronise with NTP.
This was apparently the cause of "id admin" not working (kerberos failing
without proper NTP sync?)
Now the basic functionalities are all OK.
Also, chronyd is disabled and ntpd is enabled after installation - good.

My nsswitch.conf now looks like this:

passwd: files sss
shadow: files sss
group:  files sss
hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks:   files
networks:   files
protocols:  files
rpc:files
services:   files sss
netgroup:   files sss
publickey:  nisplus
automount:  files sss
aliases:files nisplus
sudoers: files sss



I am left with 2 issues:

1) Is the above expected? Do I have to stop chronyd manually? Or is it a
bug?
2) DNS update still does not work


The latest installation log:


$ systemctl stop chronyd
$ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
Discovery was successful!
Hostname: meson.hq.example.com
Realm: HQ.EXAMPLE.COM
DNS Domain: hq.example.com
IPA Server: ipa.hq.example.com
BaseDN: dc=hq,dc=example,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
User authorized to enroll computers: User authorized to enroll computers:
admin
Password for ad...@hq.example.com:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
Valid From:  Mon Mar 16 18:44:35 2015 UTC
Valid Until: Fri Mar 16 18:44:35 2035 UTC

Enrolled in IPA realm HQ.EXAMPLE.COM
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
trying https://ipa.hq.example.com/ipa/json
Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
Forwarding 'ca_is_enabled' to json server 'https://ipa.hq.example.com
/ipa/json'
Systemwide CA database updated.
Added CA certificates to the default NSS database.
Hostname (meson.hq.example.com) not found in DNS
*Failed to update DNS records.*
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json'
*Could not update DNS SSHFP records.*
SSSD enabled
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring hq.example.com as NIS domain.
Client configuration complete.

$ id admin
uid=117200(admin) gid=117200(admins) groups=117200(admins)




On 22 March 2015 at 21:04, Jakub Hrozek  wrote:

> On Sun, Mar 22, 2015 at 04:24:49PM +0100, Roberto Cornacchia wrote:
> > Thanks Rob.
> >
> > Knowing that /etc/nsswitch.conf is created wrongly is a step forward,
> > although we don't know why that happens yet.
> > I'm not very keen on fixing it post-installation (except if this is just
> to
> > learn more about the issue), even if this seems to solve problems. I'm
> not
> > going to deploy freeIPA for real before I can at least run successfully a
> > plain installation.
>
> Hi,
>
> I find it a bit unexpected that the client system didn't have
> nsswitch.conf configured..I've never seen the client installation fail
> in this particular way.
>
> For debugging SSSD issues, we've created a new troubleshooting page
> upstream that should walk you through the config:
> https://fedorahosted.org/sssd/wiki/Troubleshooting
> maybe this article would also help:
> https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/
>
> But most improtantly, I wouldn't expect to see any issues as long as
> you use ipa-client-install. I guess re-enrolling the client would be the
> fastest way forward?
>
> --
> Manage your subscription for the Freeipa-users mailing

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

Thanks Rob.

Knowing that /etc/nsswitch.conf is created wrongly is a step forward,
although we don't know why that happens yet.
I'm not very keen on fixing it post-installation (except if this is just to
learn more about the issue), even if this seems to solve problems. I'm not
going to deploy freeIPA for real before I can at least run successfully a
plain installation.

It seems SELinux can be ruled out as well.
I switched to permissive mode and tried again, no difference.

And so far I haven't been able to find anything useful in the logs.

What strikes me is that these are really a plain and up to date FC21
machines, and my deployment was as from the book. The last of the settings
you'd expect issues from.

Can anyone (user or developer) confirm successful deployment of both server
and client on up-to-date (updated this week) FC21 systems? I know it's
maybe a bit far-fetched, but could any of the latest FC updates have
created the issue?

Roberto


On 21 March 2015 at 17:26, Rob Crittenden  wrote:

> Roberto Cornacchia wrote:
> > Hi Rob,
> >
> > Yes, sssd is running and this is sssd.conf:
> >
> > [domain/hq.example.com <http://hq.example.com>]
> > debug_level=9
> > cache_credentials = True
> > krb5_store_password_if_offline = True
> > ipa_domain = hq.example.com <http://hq.example.com>
> > id_provider = ipa
> > auth_provider = ipa
> > access_provider = ipa
> > ipa_hostname = meson.hq.example.com
> > chpass_provider = ipa
> > ipa_server = _srv_, ipa.hq.example.com
> > ldap_tls_cacert = /etc/ipa/ca.crt
> > [sssd]
> > services = nss, sudo, pam, ssh
> > config_file_version = 2
> >
> > domains = hq.example.com
> > [nss]
> > homedir_substring = /home
> > debug_level=9
> >
> > [pam]
> >
> > [sudo]
> >
> > [autofs]
> >
> > [ssh]
> >
> > [pac]
> >
> > [ifp]
>
> Ok, that's good. Maybe authconfig didn't do the right thing. I'd add sss
> to these values in /etc/nsswitch.conf, grepp'd from mine:
>
> passwd: files sss
> shadow: files sss
> group:  files sss
> services:   files sss
> netgroup:   files sss
> automount:  files sss
> sudoers:sss
>
> You've got quite a mix of odd things happening during install. It seems
> like DNS and firewall can be ruled out given that lots of other
> operations are working fine, and you've confirmed that NTP works
> pre-install.
>
> I guess working on a cleanish system, the things I'd look for on both
> client and server are the system logs to see if any errors are being
> thrown to syslog or service-specific logs.
>
> And I'd check for SELinux errors on the client if you're in enforcing mode.
>
> rob
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

Hi Rob,

Yes, sssd is running and this is sssd.conf:

[domain/hq.example.com]
debug_level=9
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = hq.example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = meson.hq.example.com
chpass_provider = ipa
ipa_server = _srv_, ipa.hq.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2

domains = hq.example.com
[nss]
homedir_substring = /home
debug_level=9

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]


On 21 March 2015 at 17:05, Rob Crittenden  wrote:

> Roberto Cornacchia wrote:
> > Indeed, id admin does not work and there is no sign of it in the log.
> >
> > From the client (with admin-tools installed):
> >
> > $ kinit admin
> > Password for ad...@hq.example.com <mailto:ad...@hq.example.com>:
> > $ ipa user-show admin
> >   User login: admin
> >   Last name: Administrator
> >   Home directory: /home/admin
> >   Login shell: /bin/bash
> >   UID: 117200
> >   GID: 117200
> >   Account disabled: False
> >   Password: True
> >   Member of groups: trust admins, admins
> >   Kerberos keys available: True
> > $ id admin
> > id: admin: no such user
> > $ getent passwd ad...@hq.spinque.com <mailto:ad...@hq.spinque.com>
> > $ grep admin /var/log/sssd/*
> > $
>
> This is because sssd is not configured in nsswitch.conf to serve
> anything other than sudo.
>
> I see in the client install log you posted in the first message of the
> thread that there was no pre-existing sssd.conf so it created a new one,
> but that shouldn't be an issue.
>
> What does sssd.conf look like and is sssd running?
>
> rob
>
> >
> >
> > On 21 March 2015 at 01:01, Dmitri Pal  > <mailto:d...@redhat.com>> wrote:
> >
> > On 03/20/2015 07:40 PM, Roberto Cornacchia wrote:
> >> Two log files in attachment (the other files in /var/log/sssd are
> >> all empty).
> >>
> >> I'll also go through the troubleshooting page again, thanks
> >>
> >
> > Do the logs include an id call for admin?
> > I do not see any instance of the word "admin" in the log.
> >
> >
> >>
> >> On 20 March 2015 at 23:03, Dmitri Pal  >> <mailto:d...@redhat.com>> wrote:
> >>
> >> On 03/20/2015 05:59 PM, Roberto Cornacchia wrote:
> >>> SSSD logs are empty so far.
> >>
> >> This is wrong.
> >>
> >>> Isn't sssd.conf written by ipa-client-install?
> >>
> >> Yes
> >>
> >>> If I raise the debug level after client installation,
> >>
> >> (and restart)
> >>
> >>> what activities do you suggest to attempt from the client?
> >> the ones that fail. getent call that returns nothing.
> >> Also try 'id'.
> >>
> >> http://www.freeipa.org/page/Troubleshooting#Client_Installation
> >> https://fedorahosted.org/sssd/wiki/Troubleshooting
> >>
> >>>
> >>>
> >>> On 20 March 2015 at 22:37, Dmitri Pal  >>> <mailto:d...@redhat.com>> wrote:
> >>>
> >>> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote:
> >>>> It certainly gets there, because the client gets in fact
> >>>> enrolled as a domain host. I can see it from the UI in
> >>>> Identity / Hosts. But not in the DNS zone.
> >>>>
> >>>> *Before ipa-client-install, all these do work: *
> >>>>
> >>>> $ ssh ipa.hq.example.com <http://ipa.hq.example.com>
> >>>> $ ntpdate ipa.hq.example.com <http://ipa.hq.example.com>
> >>>> $ ldapsearch -x -h ipa.hq.example.com
> >>>> <http://ipa.hq.example.com> -b dc=hq,dc=example,dc=com
> >>>> uid=admin
> >>>>
> >>>>
> >>>> *After running ipa-client-install, all these do work:*
> >>>>
> >>>> $ kinit admin
> >>>> Password for ad...@hq.example.com
> >>>> <mailto:ad...@hq.example.com>:
> >>>> $ ipa dnszone-show --all
> >>>> [...]
> >>>> $ ntpq -p
> >>&g

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

Indeed, id admin does not work and there is no sign of it in the log.

>From the client (with admin-tools installed):

$ kinit admin
Password for ad...@hq.example.com:
$ ipa user-show admin
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 117200
  GID: 117200
  Account disabled: False
  Password: True
  Member of groups: trust admins, admins
  Kerberos keys available: True
$ id admin
id: admin: no such user
$ getent passwd ad...@hq.spinque.com
$ grep admin /var/log/sssd/*
$


On 21 March 2015 at 01:01, Dmitri Pal  wrote:

>  On 03/20/2015 07:40 PM, Roberto Cornacchia wrote:
>
> Two log files in attachment (the other files in /var/log/sssd are all
> empty).
>
>  I'll also go through the troubleshooting page again, thanks
>
>
> Do the logs include an id call for admin?
> I do not see any instance of the word "admin" in the log.
>
>
>
> On 20 March 2015 at 23:03, Dmitri Pal  wrote:
>
>>  On 03/20/2015 05:59 PM, Roberto Cornacchia wrote:
>>
>> SSSD logs are empty so far.
>>
>>
>>  This is wrong.
>>
>>  Isn't sssd.conf written by ipa-client-install?
>>
>>
>>  Yes
>>
>>  If I raise the debug level after client installation,
>>
>>
>>  (and restart)
>>
>>   what activities do you suggest to attempt from the client?
>>
>>  the ones that fail. getent call that returns nothing.
>> Also try 'id'.
>>
>> http://www.freeipa.org/page/Troubleshooting#Client_Installation
>> https://fedorahosted.org/sssd/wiki/Troubleshooting
>>
>>
>>
>> On 20 March 2015 at 22:37, Dmitri Pal  wrote:
>>
>>>  On 03/20/2015 05:28 PM, Roberto Cornacchia wrote:
>>>
>>>  It certainly gets there, because the client gets in fact enrolled as a
>>> domain host. I can see it from the UI in Identity / Hosts. But not in the
>>> DNS zone.
>>>
>>>  *Before ipa-client-install, all these do work: *
>>>
>>>  $ ssh ipa.hq.example.com
>>> $ ntpdate ipa.hq.example.com
>>> $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com
>>> uid=admin
>>>
>>>
>>>  *After running ipa-client-install, all these do work:*
>>>
>>>  $ kinit admin
>>> Password for ad...@hq.example.com:
>>>  $ ipa dnszone-show --all
>>>  [...]
>>> $ ntpq -p
>>>  remote   refid  st t when poll reach   delay   offset
>>>  jitter
>>>
>>> ==
>>> *ipa.hq.example. 131.155.140.130  3 u   19   6410.415   -0.006
>>> 0.000
>>>  LOCAL(0).LOCL.   5 l-   6400.0000.000
>>> 0.000
>>>
>>>  *But this does NOT work:*
>>> $ getent passwd ad...@hq.example.com
>>>
>>>
>>> What do SSSD logs show on the client?
>>> Please rise the SSSD debug_level and provide SSSD logs.
>>>
>>>
>>>  *On the server, in /var/log/krb5kdc.log, I see many of these:*
>>>
>>>  Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6
>>> etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH:
>>> ad...@hq.example.com for krbtgt/hq.example@hq.example.com,
>>> Additional pre-authentication required
>>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6
>>> etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797,
>>> etypes {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/
>>> hq.example@hq.example.com
>>>
>>>
>>>  This is not an error. It is a normal user authentication.
>>> OK so it is DNS that is not working. Is DNS server running on the server?
>>> What do Bind logs show?
>>>
>>>
>>>
>>>  192.168.0.207 is the IP of the client I'm trying to install. However,
>>> higher up in the log, I also see such errors for the ipa server itself.
>>>
>>>  On 20 March 2015 at 20:24, Dmitri Pal  wrote:
>>>
>>>>  On 03/20/2015 02:48 PM, Roberto Cornacchia wrote:
>>>>
>>>> No, all real machines.
>>>>
>>>>  I'm really sorry it's taking so much of your time.
>>>> I had tried almost everything on a VM setting first, and everything was
>>>> fine.
>>>> Everything always works fine, until you actually need it.
>>>>
>>>>
>>>>
>>>>  We try to help as much as we can.
&g

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

/etc/nsswitch.conf:

passwd: files
shadow: files
group:  files
hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks:   files
networks:   files
protocols:  files
rpc:files
services:   files
netgroup:   files
publickey:  nisplus
automount:  files
aliases:files nisplus
sudoers: files sss
On 21 Mar 2015 01:06, "Dmitri Pal"  wrote:

>  On 03/20/2015 07:56 PM, Roberto Cornacchia wrote:
>
> From https://fedorahosted.org/sssd/wiki/Troubleshooting, I see that
> invoking getent should correspond to seeing command 17 invoked in the nss
> log:
>
>  Something like:
> [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input
> [admin].
>
>  I don't see any command invocation in my sss_dnss log
>
>
> Forgot to reply to the list...
>
> Right.
> So how does your nsswitch.conf looks like?
>
>
>  On 21 March 2015 at 00:51, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>> Ah, I see, I had forgotten to enable debut in the nss section. Here its
>> log.
>>
>> On 21 March 2015 at 00:40, Roberto Cornacchia <
>> roberto.cornacc...@gmail.com> wrote:
>>
>>> Two log files in attachment (the other files in /var/log/sssd are all
>>> empty).
>>>
>>>  I'll also go through the troubleshooting page again, thanks
>>>
>>>
>>> On 20 March 2015 at 23:03, Dmitri Pal  wrote:
>>>
>>>>  On 03/20/2015 05:59 PM, Roberto Cornacchia wrote:
>>>>
>>>> SSSD logs are empty so far.
>>>>
>>>>
>>>>  This is wrong.
>>>>
>>>>  Isn't sssd.conf written by ipa-client-install?
>>>>
>>>>
>>>>  Yes
>>>>
>>>>  If I raise the debug level after client installation,
>>>>
>>>>
>>>>  (and restart)
>>>>
>>>>   what activities do you suggest to attempt from the client?
>>>>
>>>>  the ones that fail. getent call that returns nothing.
>>>> Also try 'id'.
>>>>
>>>> http://www.freeipa.org/page/Troubleshooting#Client_Installation
>>>> https://fedorahosted.org/sssd/wiki/Troubleshooting
>>>>
>>>>
>>>>
>>>> On 20 March 2015 at 22:37, Dmitri Pal  wrote:
>>>>
>>>>>  On 03/20/2015 05:28 PM, Roberto Cornacchia wrote:
>>>>>
>>>>>  It certainly gets there, because the client gets in fact enrolled as
>>>>> a domain host. I can see it from the UI in Identity / Hosts. But not in 
>>>>> the
>>>>> DNS zone.
>>>>>
>>>>>  *Before ipa-client-install, all these do work: *
>>>>>
>>>>>  $ ssh ipa.hq.example.com
>>>>> $ ntpdate ipa.hq.example.com
>>>>> $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com
>>>>> uid=admin
>>>>>
>>>>>
>>>>>  *After running ipa-client-install, all these do work:*
>>>>>
>>>>>  $ kinit admin
>>>>> Password for ad...@hq.example.com:
>>>>>  $ ipa dnszone-show --all
>>>>>  [...]
>>>>> $ ntpq -p
>>>>>  remote   refid  st t when poll reach   delay   offset
>>>>>  jitter
>>>>>
>>>>> ==
>>>>> *ipa.hq.example. 131.155.140.130  3 u   19   6410.415   -0.006
>>>>>   0.000
>>>>>  LOCAL(0).LOCL.   5 l-   6400.0000.000
>>>>>   0.000
>>>>>
>>>>>  *But this does NOT work:*
>>>>> $ getent passwd ad...@hq.example.com
>>>>>
>>>>>
>>>>> What do SSSD logs show on the client?
>>>>> Please rise the SSSD debug_level and provide SSSD logs.
>>>>>
>>>>>
>>>>>  *On the server, in /var/log/krb5kdc.log, I see many of these:*
>>>>>
>>>>>  Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6
>>>>> etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH:
>>>>> ad...@hq.example.com for krbtgt/hq.example@hq.example.com,
>>>>> Additional pre-authentication required
>>>>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): A

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

>From https://fedorahosted.org/sssd/wiki/Troubleshooting, I see that
invoking getent should correspond to seeing command 17 invoked in the nss
log:

Something like:
[sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input
[admin].

I don't see any command invocation in my sss_dnss log

On 21 March 2015 at 00:51, Roberto Cornacchia 
wrote:

> Ah, I see, I had forgotten to enable debut in the nss section. Here its
> log.
>
> On 21 March 2015 at 00:40, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>> Two log files in attachment (the other files in /var/log/sssd are all
>> empty).
>>
>> I'll also go through the troubleshooting page again, thanks
>>
>>
>> On 20 March 2015 at 23:03, Dmitri Pal  wrote:
>>
>>>  On 03/20/2015 05:59 PM, Roberto Cornacchia wrote:
>>>
>>> SSSD logs are empty so far.
>>>
>>>
>>> This is wrong.
>>>
>>>  Isn't sssd.conf written by ipa-client-install?
>>>
>>>
>>> Yes
>>>
>>>  If I raise the debug level after client installation,
>>>
>>>
>>> (and restart)
>>>
>>>   what activities do you suggest to attempt from the client?
>>>
>>> the ones that fail. getent call that returns nothing.
>>> Also try 'id'.
>>>
>>> http://www.freeipa.org/page/Troubleshooting#Client_Installation
>>> https://fedorahosted.org/sssd/wiki/Troubleshooting
>>>
>>>
>>>
>>> On 20 March 2015 at 22:37, Dmitri Pal  wrote:
>>>
>>>>  On 03/20/2015 05:28 PM, Roberto Cornacchia wrote:
>>>>
>>>>  It certainly gets there, because the client gets in fact enrolled as
>>>> a domain host. I can see it from the UI in Identity / Hosts. But not in the
>>>> DNS zone.
>>>>
>>>>  *Before ipa-client-install, all these do work: *
>>>>
>>>>  $ ssh ipa.hq.example.com
>>>> $ ntpdate ipa.hq.example.com
>>>> $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com
>>>> uid=admin
>>>>
>>>>
>>>>  *After running ipa-client-install, all these do work:*
>>>>
>>>>  $ kinit admin
>>>> Password for ad...@hq.example.com:
>>>>  $ ipa dnszone-show --all
>>>>  [...]
>>>> $ ntpq -p
>>>>  remote   refid  st t when poll reach   delay   offset
>>>>  jitter
>>>>
>>>> ==
>>>> *ipa.hq.example. 131.155.140.130  3 u   19   6410.415   -0.006
>>>>   0.000
>>>>  LOCAL(0).LOCL.   5 l-   6400.0000.000
>>>>   0.000
>>>>
>>>>  *But this does NOT work:*
>>>> $ getent passwd ad...@hq.example.com
>>>>
>>>>
>>>> What do SSSD logs show on the client?
>>>> Please rise the SSSD debug_level and provide SSSD logs.
>>>>
>>>>
>>>>  *On the server, in /var/log/krb5kdc.log, I see many of these:*
>>>>
>>>>  Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6
>>>> etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH:
>>>> ad...@hq.example.com for krbtgt/hq.example@hq.example.com,
>>>> Additional pre-authentication required
>>>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6
>>>> etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797,
>>>> etypes {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/
>>>> hq.example@hq.example.com
>>>>
>>>>
>>>>  This is not an error. It is a normal user authentication.
>>>> OK so it is DNS that is not working. Is DNS server running on the
>>>> server?
>>>> What do Bind logs show?
>>>>
>>>>
>>>>
>>>>  192.168.0.207 is the IP of the client I'm trying to install. However,
>>>> higher up in the log, I also see such errors for the ipa server itself.
>>>>
>>>>  On 20 March 2015 at 20:24, Dmitri Pal  wrote:
>>>>
>>>>>  On 03/20/2015 02:48 PM, Roberto Cornacchia wrote:
>>>>>
>>>>> No, all real machines.
>>>>>
>>>>>  I'm really sorry it's taking so much of your time.
>>>>> I had tried almost everything on a VM 

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

Ah, I see, I had forgotten to enable debut in the nss section. Here its log.

On 21 March 2015 at 00:40, Roberto Cornacchia 
wrote:

> Two log files in attachment (the other files in /var/log/sssd are all
> empty).
>
> I'll also go through the troubleshooting page again, thanks
>
>
> On 20 March 2015 at 23:03, Dmitri Pal  wrote:
>
>>  On 03/20/2015 05:59 PM, Roberto Cornacchia wrote:
>>
>> SSSD logs are empty so far.
>>
>>
>> This is wrong.
>>
>>  Isn't sssd.conf written by ipa-client-install?
>>
>>
>> Yes
>>
>>  If I raise the debug level after client installation,
>>
>>
>> (and restart)
>>
>>   what activities do you suggest to attempt from the client?
>>
>> the ones that fail. getent call that returns nothing.
>> Also try 'id'.
>>
>> http://www.freeipa.org/page/Troubleshooting#Client_Installation
>> https://fedorahosted.org/sssd/wiki/Troubleshooting
>>
>>
>>
>> On 20 March 2015 at 22:37, Dmitri Pal  wrote:
>>
>>>  On 03/20/2015 05:28 PM, Roberto Cornacchia wrote:
>>>
>>>  It certainly gets there, because the client gets in fact enrolled as a
>>> domain host. I can see it from the UI in Identity / Hosts. But not in the
>>> DNS zone.
>>>
>>>  *Before ipa-client-install, all these do work: *
>>>
>>>  $ ssh ipa.hq.example.com
>>> $ ntpdate ipa.hq.example.com
>>> $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com
>>> uid=admin
>>>
>>>
>>>  *After running ipa-client-install, all these do work:*
>>>
>>>  $ kinit admin
>>> Password for ad...@hq.example.com:
>>>  $ ipa dnszone-show --all
>>>  [...]
>>> $ ntpq -p
>>>  remote   refid  st t when poll reach   delay   offset
>>>  jitter
>>>
>>> ==
>>> *ipa.hq.example. 131.155.140.130  3 u   19   6410.415   -0.006
>>> 0.000
>>>  LOCAL(0).LOCL.   5 l-   6400.0000.000
>>> 0.000
>>>
>>>  *But this does NOT work:*
>>> $ getent passwd ad...@hq.example.com
>>>
>>>
>>> What do SSSD logs show on the client?
>>> Please rise the SSSD debug_level and provide SSSD logs.
>>>
>>>
>>>  *On the server, in /var/log/krb5kdc.log, I see many of these:*
>>>
>>>  Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6
>>> etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH:
>>> ad...@hq.example.com for krbtgt/hq.example@hq.example.com,
>>> Additional pre-authentication required
>>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6
>>> etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797,
>>> etypes {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/
>>> hq.example@hq.example.com
>>>
>>>
>>>  This is not an error. It is a normal user authentication.
>>> OK so it is DNS that is not working. Is DNS server running on the server?
>>> What do Bind logs show?
>>>
>>>
>>>
>>>  192.168.0.207 is the IP of the client I'm trying to install. However,
>>> higher up in the log, I also see such errors for the ipa server itself.
>>>
>>>  On 20 March 2015 at 20:24, Dmitri Pal  wrote:
>>>
>>>>  On 03/20/2015 02:48 PM, Roberto Cornacchia wrote:
>>>>
>>>> No, all real machines.
>>>>
>>>>  I'm really sorry it's taking so much of your time.
>>>> I had tried almost everything on a VM setting first, and everything was
>>>> fine.
>>>> Everything always works fine, until you actually need it.
>>>>
>>>>
>>>>
>>>>  We try to help as much as we can.
>>>> Can you do LDAP lookups as a directory manager from client host to
>>>> server?
>>>> Can you ssh from client to server?
>>>>
>>>> When you try to install client is there anything in the logs on the
>>>> server? Does it even get there?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 20 March 2015 at 19:41, Dmitri Pal  wrote:
>>>>
>>>>>  On 03/20/2015 01:57 PM, Roberto Cornacchia wrote:
>>>>>
>>>>> But the ipa server itself is also enrolled as a client, 

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

SSSD logs are empty so far.
Isn't sssd.conf written by ipa-client-install? If I raise the debug level
after client installation, what activities do you suggest to attempt from
the client?


On 20 March 2015 at 22:37, Dmitri Pal  wrote:

>  On 03/20/2015 05:28 PM, Roberto Cornacchia wrote:
>
>  It certainly gets there, because the client gets in fact enrolled as a
> domain host. I can see it from the UI in Identity / Hosts. But not in the
> DNS zone.
>
>  *Before ipa-client-install, all these do work: *
>
>  $ ssh ipa.hq.example.com
> $ ntpdate ipa.hq.example.com
> $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com uid=admin
>
>
>  *After running ipa-client-install, all these do work:*
>
>  $ kinit admin
> Password for ad...@hq.example.com:
>  $ ipa dnszone-show --all
>  [...]
> $ ntpq -p
>  remote   refid  st t when poll reach   delay   offset
>  jitter
>
> ==
> *ipa.hq.example. 131.155.140.130  3 u   19   6410.415   -0.006
> 0.000
>  LOCAL(0).LOCL.   5 l-   6400.0000.000
> 0.000
>
>  *But this does NOT work:*
> $ getent passwd ad...@hq.example.com
>
>
> What do SSSD logs show on the client?
> Please rise the SSSD debug_level and provide SSSD logs.
>
>
>  *On the server, in /var/log/krb5kdc.log, I see many of these:*
>
>  Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes
> {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: ad...@hq.example.com
> for krbtgt/hq.example@hq.example.com, Additional pre-authentication
> required
> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes
> {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes
> {rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/
> hq.example@hq.example.com
>
>
> This is not an error. It is a normal user authentication.
> OK so it is DNS that is not working. Is DNS server running on the server?
> What do Bind logs show?
>
>
>
>  192.168.0.207 is the IP of the client I'm trying to install. However,
> higher up in the log, I also see such errors for the ipa server itself.
>
>  On 20 March 2015 at 20:24, Dmitri Pal  wrote:
>
>>  On 03/20/2015 02:48 PM, Roberto Cornacchia wrote:
>>
>> No, all real machines.
>>
>>  I'm really sorry it's taking so much of your time.
>> I had tried almost everything on a VM setting first, and everything was
>> fine.
>> Everything always works fine, until you actually need it.
>>
>>
>>
>>  We try to help as much as we can.
>> Can you do LDAP lookups as a directory manager from client host to server?
>> Can you ssh from client to server?
>>
>> When you try to install client is there anything in the logs on the
>> server? Does it even get there?
>>
>>
>>
>>
>>
>>
>> On 20 March 2015 at 19:41, Dmitri Pal  wrote:
>>
>>>  On 03/20/2015 01:57 PM, Roberto Cornacchia wrote:
>>>
>>> But the ipa server itself is also enrolled as a client, just after the
>>> server installation, right?. And that worked fine.
>>>
>>>
>>>  Are these VMs?
>>> There have been a similar case when the network was not set properly for
>>> the virtual test environment.
>>>
>>>
>>>
>>> On 20 March 2015 at 18:55, Roberto Cornacchia <
>>> roberto.cornacc...@gmail.com> wrote:
>>>
>>>>  No, sorry about the confusion, i shouldn't have posted so quickly.
>>>>
>>>> When I use the correct domain (hq.example.com), then I really get all
>>>> the same errors as before, also in the new client.
>>>>
>>>>
>>>>
>>>>   On 20 Mar 2015 18:39, "Dmitri Pal"  wrote:
>>>>
>>>>>   On 03/20/2015 01:25 PM, Roberto Cornacchia wrote:
>>>>>
>>>>> Oops. Not true, forget last email.
>>>>>
>>>>>  This secon client installation went different just because it took
>>>>> the wrong domain.
>>>>> It used *example.com <http://example.com>* (what was previously set)
>>>>> instead of *hq.example.com <http://hq.example.com>*
>>>>>
>>>>>  Uninstalled, tried again with --hostname=photon.hq.example.com
>>>>> And then it behaves precisely like the previous client.
>>>>>
>>>>>  So something seems wrong in the server.
>>>>>
>>>>> On 20 March 2015 at 18:

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

It certainly gets there, because the client gets in fact enrolled as a
domain host. I can see it from the UI in Identity / Hosts. But not in the
DNS zone.

*Before ipa-client-install, all these do work: *

$ ssh ipa.hq.example.com
$ ntpdate ipa.hq.example.com
$ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com uid=admin


*After running ipa-client-install, all these do work:*

$ kinit admin
Password for ad...@hq.example.com:
$ ipa dnszone-show --all
[...]
$ ntpq -p
 remote   refid  st t when poll reach   delay   offset
 jitter
==
*ipa.hq.example. 131.155.140.130  3 u   19   6410.415   -0.006
0.000
 LOCAL(0).LOCL.   5 l-   6400.0000.000
0.000

*But this does NOT work:*
$ getent passwd ad...@hq.example.com

*On the server, in /var/log/krb5kdc.log, I see many of these:*

Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes
{18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: ad...@hq.example.com
for krbtgt/hq.example@hq.example.com, Additional pre-authentication
required
Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes
{18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes
{rep=18 tkt=18 ses=18}, ad...@hq.example.com for krbtgt/
hq.example@hq.example.com

192.168.0.207 is the IP of the client I'm trying to install. However,
higher up in the log, I also see such errors for the ipa server itself.

On 20 March 2015 at 20:24, Dmitri Pal  wrote:

>  On 03/20/2015 02:48 PM, Roberto Cornacchia wrote:
>
> No, all real machines.
>
>  I'm really sorry it's taking so much of your time.
> I had tried almost everything on a VM setting first, and everything was
> fine.
> Everything always works fine, until you actually need it.
>
>
>
> We try to help as much as we can.
> Can you do LDAP lookups as a directory manager from client host to server?
> Can you ssh from client to server?
>
> When you try to install client is there anything in the logs on the
> server? Does it even get there?
>
>
>
>
>
>
> On 20 March 2015 at 19:41, Dmitri Pal  wrote:
>
>>  On 03/20/2015 01:57 PM, Roberto Cornacchia wrote:
>>
>> But the ipa server itself is also enrolled as a client, just after the
>> server installation, right?. And that worked fine.
>>
>>
>>  Are these VMs?
>> There have been a similar case when the network was not set properly for
>> the virtual test environment.
>>
>>
>>
>> On 20 March 2015 at 18:55, Roberto Cornacchia <
>> roberto.cornacc...@gmail.com> wrote:
>>
>>>  No, sorry about the confusion, i shouldn't have posted so quickly.
>>>
>>> When I use the correct domain (hq.example.com), then I really get all
>>> the same errors as before, also in the new client.
>>>
>>>
>>>
>>>   On 20 Mar 2015 18:39, "Dmitri Pal"  wrote:
>>>
>>>>   On 03/20/2015 01:25 PM, Roberto Cornacchia wrote:
>>>>
>>>> Oops. Not true, forget last email.
>>>>
>>>>  This secon client installation went different just because it took
>>>> the wrong domain.
>>>> It used *example.com <http://example.com>* (what was previously set)
>>>> instead of *hq.example.com <http://hq.example.com>*
>>>>
>>>>  Uninstalled, tried again with --hostname=photon.hq.example.com
>>>> And then it behaves precisely like the previous client.
>>>>
>>>>  So something seems wrong in the server.
>>>>
>>>> On 20 March 2015 at 18:18, Roberto Cornacchia <
>>>> roberto.cornacc...@gmail.com> wrote:
>>>>
>>>>>  Update:
>>>>> I tried from another client. Also FC21, same network, same settings
>>>>> from the same DHCP.
>>>>> But obviously it must have something different because it partially
>>>>> succeeded.
>>>>>
>>>>>  - I do not get errors about LDAP users.
>>>>> - I do not get errors about DNS update
>>>>>
>>>>>  However:
>>>>> - I still get the initial error about NTP
>>>>> - The host is enrolled, but not added to the DNS zone
>>>>>
>>>>>  Now, I don't care much about the previous client. It was pretty much
>>>>> empty and can re-install Fedora from scratch.
>>>>>
>>>>>  But I'd like to understand if this is still a problem.
>>>>> It should be added to the zone, shouldn't it?
>>>>>
>>

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

No, all real machines.

I'm really sorry it's taking so much of your time.
I had tried almost everything on a VM setting first, and everything was
fine.
Everything always works fine, until you actually need it.


On 20 March 2015 at 19:41, Dmitri Pal  wrote:

>  On 03/20/2015 01:57 PM, Roberto Cornacchia wrote:
>
> But the ipa server itself is also enrolled as a client, just after the
> server installation, right?. And that worked fine.
>
>
> Are these VMs?
> There have been a similar case when the network was not set properly for
> the virtual test environment.
>
>
>
> On 20 March 2015 at 18:55, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>>  No, sorry about the confusion, i shouldn't have posted so quickly.
>>
>> When I use the correct domain (hq.example.com), then I really get all
>> the same errors as before, also in the new client.
>>
>>
>>
>>   On 20 Mar 2015 18:39, "Dmitri Pal"  wrote:
>>
>>>   On 03/20/2015 01:25 PM, Roberto Cornacchia wrote:
>>>
>>> Oops. Not true, forget last email.
>>>
>>>  This secon client installation went different just because it took the
>>> wrong domain.
>>> It used *example.com <http://example.com>* (what was previously set)
>>> instead of *hq.example.com <http://hq.example.com>*
>>>
>>>  Uninstalled, tried again with --hostname=photon.hq.example.com
>>> And then it behaves precisely like the previous client.
>>>
>>>  So something seems wrong in the server.
>>>
>>> On 20 March 2015 at 18:18, Roberto Cornacchia <
>>> roberto.cornacc...@gmail.com> wrote:
>>>
>>>>  Update:
>>>> I tried from another client. Also FC21, same network, same settings
>>>> from the same DHCP.
>>>> But obviously it must have something different because it partially
>>>> succeeded.
>>>>
>>>>  - I do not get errors about LDAP users.
>>>> - I do not get errors about DNS update
>>>>
>>>>  However:
>>>> - I still get the initial error about NTP
>>>> - The host is enrolled, but not added to the DNS zone
>>>>
>>>>  Now, I don't care much about the previous client. It was pretty much
>>>> empty and can re-install Fedora from scratch.
>>>>
>>>>  But I'd like to understand if this is still a problem.
>>>> It should be added to the zone, shouldn't it?
>>>>
>>>>  $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
>>>> Discovery was successful!
>>>> Hostname: photon.example.com
>>>>  Realm: HQ.EXAMPLE.COM
>>>> DNS Domain: hq.example.com
>>>> IPA Server: ipa.hq.example.com
>>>> BaseDN: dc=hq,dc=example,dc=com
>>>>
>>>>  Continue to configure the system with these values? [no]: yes
>>>> Synchronizing time with KDC...
>>>> *Unable to sync time with IPA NTP server, assuming the time is in sync.
>>>> Please check that 123 UDP port is opened.*
>>>> User authorized to enroll computers: admin
>>>> Password for ad...@hq.example.com:
>>>> Successfully retrieved CA cert
>>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
>>>> Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
>>>> Valid From:  Mon Mar 16 18:44:35 2015 UTC
>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC
>>>>
>>>>  Enrolled in IPA realm HQ.EXAMPLE.COM
>>>> Created /etc/ipa/default.conf
>>>> New SSSD config will be created
>>>> Configured sudoers in /etc/nsswitch.conf
>>>> Configured /etc/sssd/sssd.conf
>>>> Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
>>>> trying https://ipa.hq.example.com/ipa/json
>>>> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
>>>> Forwarding 'ca_is_enabled' to json server '
>>>> https://ipa.hq.example.com/ipa/json'
>>>> Systemwide CA database updated.
>>>> Added CA certificates to the default NSS database.
>>>>   Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
>>>>  Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
>>>>  Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
>>>>  Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
>>>>  Forwarding 'host_mod' to json server '
>>>&

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

But the ipa server itself is also enrolled as a client, just after the
server installation, right?. And that worked fine.

On 20 March 2015 at 18:55, Roberto Cornacchia 
wrote:

> No, sorry about the confusion, i shouldn't have posted so quickly.
>
> When I use the correct domain (hq.example.com), then I really get all the
> same errors as before, also in the new client.
>
>
>
> On 20 Mar 2015 18:39, "Dmitri Pal"  wrote:
>
>>  On 03/20/2015 01:25 PM, Roberto Cornacchia wrote:
>>
>> Oops. Not true, forget last email.
>>
>>  This secon client installation went different just because it took the
>> wrong domain.
>> It used *example.com <http://example.com>* (what was previously set)
>> instead of *hq.example.com <http://hq.example.com>*
>>
>>  Uninstalled, tried again with --hostname=photon.hq.example.com
>> And then it behaves precisely like the previous client.
>>
>>  So something seems wrong in the server.
>>
>> On 20 March 2015 at 18:18, Roberto Cornacchia <
>> roberto.cornacc...@gmail.com> wrote:
>>
>>>  Update:
>>> I tried from another client. Also FC21, same network, same settings from
>>> the same DHCP.
>>> But obviously it must have something different because it partially
>>> succeeded.
>>>
>>>  - I do not get errors about LDAP users.
>>> - I do not get errors about DNS update
>>>
>>>  However:
>>> - I still get the initial error about NTP
>>> - The host is enrolled, but not added to the DNS zone
>>>
>>>  Now, I don't care much about the previous client. It was pretty much
>>> empty and can re-install Fedora from scratch.
>>>
>>>  But I'd like to understand if this is still a problem.
>>> It should be added to the zone, shouldn't it?
>>>
>>>  $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
>>> Discovery was successful!
>>> Hostname: photon.example.com
>>>  Realm: HQ.EXAMPLE.COM
>>> DNS Domain: hq.example.com
>>> IPA Server: ipa.hq.example.com
>>> BaseDN: dc=hq,dc=example,dc=com
>>>
>>>  Continue to configure the system with these values? [no]: yes
>>> Synchronizing time with KDC...
>>> *Unable to sync time with IPA NTP server, assuming the time is in sync.
>>> Please check that 123 UDP port is opened.*
>>> User authorized to enroll computers: admin
>>> Password for ad...@hq.example.com:
>>> Successfully retrieved CA cert
>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
>>> Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
>>> Valid From:  Mon Mar 16 18:44:35 2015 UTC
>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC
>>>
>>>  Enrolled in IPA realm HQ.EXAMPLE.COM
>>> Created /etc/ipa/default.conf
>>> New SSSD config will be created
>>> Configured sudoers in /etc/nsswitch.conf
>>> Configured /etc/sssd/sssd.conf
>>> Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
>>> trying https://ipa.hq.example.com/ipa/json
>>> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
>>> Forwarding 'ca_is_enabled' to json server '
>>> https://ipa.hq.example.com/ipa/json'
>>> Systemwide CA database updated.
>>> Added CA certificates to the default NSS database.
>>>   Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
>>>  Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
>>>  Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
>>>  Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
>>>  Forwarding 'host_mod' to json server '
>>> https://ipa.hq.example.com/ipa/json'
>>> *Could not update DNS SSHFP records.*
>>> SSSD enabled
>>> Configured /etc/openldap/ldap.conf
>>>  NTP enabled
>>> Configured /etc/ssh/ssh_config
>>> Configured /etc/ssh/sshd_config
>>> Configuring hq.example.com as NIS domain.
>>> Client configuration complete.
>>>
>>>
>>
>>
>>
>> It is different. It does not have the same failure about admin as you had
>> in the first email.
>> So may be it is the permissions issue and a separate NTP issue?
>> Did you play with any permissions on the server side?
>>
>>
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager IdM portfolio
>> Red Hat, Inc.
>>
>>
>> --
>> 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] ipa-client-install failure

[Roberto Cornacchia]

No, sorry about the confusion, i shouldn't have posted so quickly.

When I use the correct domain (hq.example.com), then I really get all the
same errors as before, also in the new client.



On 20 Mar 2015 18:39, "Dmitri Pal"  wrote:

>  On 03/20/2015 01:25 PM, Roberto Cornacchia wrote:
>
> Oops. Not true, forget last email.
>
>  This secon client installation went different just because it took the
> wrong domain.
> It used *example.com <http://example.com>* (what was previously set)
> instead of *hq.example.com <http://hq.example.com>*
>
>  Uninstalled, tried again with --hostname=photon.hq.example.com
> And then it behaves precisely like the previous client.
>
>  So something seems wrong in the server.
>
> On 20 March 2015 at 18:18, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
>
>>  Update:
>> I tried from another client. Also FC21, same network, same settings from
>> the same DHCP.
>> But obviously it must have something different because it partially
>> succeeded.
>>
>>  - I do not get errors about LDAP users.
>> - I do not get errors about DNS update
>>
>>  However:
>> - I still get the initial error about NTP
>> - The host is enrolled, but not added to the DNS zone
>>
>>  Now, I don't care much about the previous client. It was pretty much
>> empty and can re-install Fedora from scratch.
>>
>>  But I'd like to understand if this is still a problem.
>> It should be added to the zone, shouldn't it?
>>
>>  $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
>> Discovery was successful!
>> Hostname: photon.example.com
>>  Realm: HQ.EXAMPLE.COM
>> DNS Domain: hq.example.com
>> IPA Server: ipa.hq.example.com
>> BaseDN: dc=hq,dc=example,dc=com
>>
>>  Continue to configure the system with these values? [no]: yes
>> Synchronizing time with KDC...
>> *Unable to sync time with IPA NTP server, assuming the time is in sync.
>> Please check that 123 UDP port is opened.*
>> User authorized to enroll computers: admin
>> Password for ad...@hq.example.com:
>> Successfully retrieved CA cert
>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
>> Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
>> Valid From:  Mon Mar 16 18:44:35 2015 UTC
>> Valid Until: Fri Mar 16 18:44:35 2035 UTC
>>
>>  Enrolled in IPA realm HQ.EXAMPLE.COM
>> Created /etc/ipa/default.conf
>> New SSSD config will be created
>> Configured sudoers in /etc/nsswitch.conf
>> Configured /etc/sssd/sssd.conf
>> Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
>> trying https://ipa.hq.example.com/ipa/json
>> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
>> Forwarding 'ca_is_enabled' to json server '
>> https://ipa.hq.example.com/ipa/json'
>> Systemwide CA database updated.
>> Added CA certificates to the default NSS database.
>>   Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
>>  Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
>>  Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
>>  Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
>>  Forwarding 'host_mod' to json server '
>> https://ipa.hq.example.com/ipa/json'
>> *Could not update DNS SSHFP records.*
>> SSSD enabled
>> Configured /etc/openldap/ldap.conf
>>  NTP enabled
>> Configured /etc/ssh/ssh_config
>> Configured /etc/ssh/sshd_config
>> Configuring hq.example.com as NIS domain.
>> Client configuration complete.
>>
>>
>
>
>
> It is different. It does not have the same failure about admin as you had
> in the first email.
> So may be it is the permissions issue and a separate NTP issue?
> Did you play with any permissions on the server side?
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
>
>
> --
> 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] ipa-client-install failure

[Roberto Cornacchia]

Oops. Not true, forget last email.

This secon client installation went different just because it took the
wrong domain.
It used *example.com <http://example.com>* (what was previously set)
instead of *hq.example.com <http://hq.example.com>*

Uninstalled, tried again with --hostname=photon.hq.example.com
And then it behaves precisely like the previous client.

So something seems wrong in the server.

On 20 March 2015 at 18:18, Roberto Cornacchia 
wrote:

> Update:
> I tried from another client. Also FC21, same network, same settings from
> the same DHCP.
> But obviously it must have something different because it partially
> succeeded.
>
> - I do not get errors about LDAP users.
> - I do not get errors about DNS update
>
> However:
> - I still get the initial error about NTP
> - The host is enrolled, but not added to the DNS zone
>
> Now, I don't care much about the previous client. It was pretty much empty
> and can re-install Fedora from scratch.
>
> But I'd like to understand if this is still a problem.
> It should be added to the zone, shouldn't it?
>
> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
> Discovery was successful!
> Hostname: photon.example.com
> Realm: HQ.EXAMPLE.COM
> DNS Domain: hq.example.com
> IPA Server: ipa.hq.example.com
> BaseDN: dc=hq,dc=example,dc=com
>
> Continue to configure the system with these values? [no]: yes
> Synchronizing time with KDC...
> *Unable to sync time with IPA NTP server, assuming the time is in sync.
> Please check that 123 UDP port is opened.*
> User authorized to enroll computers: admin
> Password for ad...@hq.example.com:
> Successfully retrieved CA cert
> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
> Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
> Valid From:  Mon Mar 16 18:44:35 2015 UTC
> Valid Until: Fri Mar 16 18:44:35 2035 UTC
>
> Enrolled in IPA realm HQ.EXAMPLE.COM
> Created /etc/ipa/default.conf
> New SSSD config will be created
> Configured sudoers in /etc/nsswitch.conf
> Configured /etc/sssd/sssd.conf
> Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
> trying https://ipa.hq.example.com/ipa/json
> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
> Forwarding 'ca_is_enabled' to json server '
> https://ipa.hq.example.com/ipa/json'
> Systemwide CA database updated.
> Added CA certificates to the default NSS database.
> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
> Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json'
> *Could not update DNS SSHFP records.*
> SSSD enabled
> Configured /etc/openldap/ldap.conf
> NTP enabled
> Configured /etc/ssh/ssh_config
> Configured /etc/ssh/sshd_config
> Configuring hq.example.com as NIS domain.
> Client configuration complete.
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

Update:
I tried from another client. Also FC21, same network, same settings from
the same DHCP.
But obviously it must have something different because it partially
succeeded.

- I do not get errors about LDAP users.
- I do not get errors about DNS update

However:
- I still get the initial error about NTP
- The host is enrolled, but not added to the DNS zone

Now, I don't care much about the previous client. It was pretty much empty
and can re-install Fedora from scratch.

But I'd like to understand if this is still a problem.
It should be added to the zone, shouldn't it?

$ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
Discovery was successful!
Hostname: photon.example.com
Realm: HQ.EXAMPLE.COM
DNS Domain: hq.example.com
IPA Server: ipa.hq.example.com
BaseDN: dc=hq,dc=example,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
*Unable to sync time with IPA NTP server, assuming the time is in sync.
Please check that 123 UDP port is opened.*
User authorized to enroll computers: admin
Password for ad...@hq.example.com:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
Valid From:  Mon Mar 16 18:44:35 2015 UTC
Valid Until: Fri Mar 16 18:44:35 2035 UTC

Enrolled in IPA realm HQ.EXAMPLE.COM
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
trying https://ipa.hq.example.com/ipa/json
Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
Forwarding 'ca_is_enabled' to json server '
https://ipa.hq.example.com/ipa/json'
Systemwide CA database updated.
Added CA certificates to the default NSS database.
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json'
*Could not update DNS SSHFP records.*
SSSD enabled
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring hq.example.com as NIS domain.
Client configuration complete.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

ipv6 re-enabled. No luck yet :(

On 20 March 2015 at 17:06, Dmitri Pal  wrote:

>  On 03/20/2015 10:56 AM, Roberto Cornacchia wrote:
>
>  The zone settings:
>
>  $ ipa dnszone-show --all
> Zone name: hq.example.com.
>   dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com
>   Zone name: hq.example.com.
>   Active zone: TRUE
>   Authoritative nameserver: ipa.hq.example.com.
>   Administrator e-mail address: hostmaster.hq.example.com.
>   SOA serial: 1426857128
>   SOA refresh: 3600
>   SOA retry: 900
>   SOA expire: 1209600
>   SOA minimum: 3600
>   BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM
> krb5-self * ; grant HQ.EXAMPLE.COM krb5-self * SSHFP;
>   Dynamic update: TRUE
>   Allow query: any;
>   Allow transfer: none;
>   nsrecord: ipa.hq.example.com.
>   objectclass: idnszone, top, idnsrecord
>
>   The DNS log doesn't mention anything about updates. It does contain
> some errors about unreachable hosts, but that's because I had a temporary
> interruption towards the gateway from the ipa server.
>
>  One thing I did after installing the IPA server is to turn off support
> for ipv6, using
> $ echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf
> $ sysctl -p
>
>  Do you think it could have any influence?
>
>
> I think it can.
> I have a vague recollection of a bug related to that is some of the
> packages we depend on or something like.
> Can you try enabling it and see if it makes a difference?
>
>
>
>
>  On 20 March 2015 at 12:31, Martin Basti  wrote:
>
>>  Hello,
>>
>> do you have enabled DNS dynamic updates for hq.example.zone?
>> You can check it in zone settings.
>>
>> Are there any log entries in dns log related to nsupdate executed from a
>> client?
>> $ journalctl -b -u named-pkcs11
>>
>>
>> On 20/03/15 09:53, Roberto Cornacchia wrote:
>>
>>  It seems so:
>>
>>  $ firewall-cmd --list-all
>> FedoraServer (default, active)
>>   interfaces: em2
>>   sources:
>>   services: cockpit dhcpv6-client ssh
>>   ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp
>> 464/udp 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp 9444/tcp
>> 9445/tcp 8011/tcp 53/udp 8082/tcp
>>   masquerade: no
>>   forward-ports:
>>   icmp-blocks:
>>   rich rules:
>>
>>
>> On 20 March 2015 at 00:53, Dmitri Pal  wrote:
>>
>>>  On 03/19/2015 05:04 PM, Roberto Cornacchia wrote:
>>>
>>>  Yes.
>>>
>>>  [root@meson ~]# cat /etc/resolv.conf
>>> search hq.example.com
>>> nameserver 192.168.0.72
>>>
>>>  Sorry from the short log I posted it's not visible, but that ip
>>> address is the address of the ipa server (ipa.hq.example.com)
>>>
>>>  [root@meson ~]# dig ipa.hq.example.com
>>>
>>>  ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ipa.hq.example.com
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238
>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
>>>
>>>  ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;ipa.hq.example.com. IN A
>>>
>>>  ;; ANSWER SECTION:
>>> ipa.hq.example.com. 1200 IN A 192.168.0.72
>>>
>>>  ;; AUTHORITY SECTION:
>>> hq.example.com. 86400 IN NS ipa.hq.example.com.
>>>
>>>  ;; Query time: 1 msec
>>> ;; SERVER: 192.168.0.72#53(192.168.0.72)
>>> ;; WHEN: do mrt 19 22:02:04 CET 2015
>>> ;; MSG SIZE  rcvd: 83
>>>
>>>
>>>
>>>  OK so you can in fact lookup the server.
>>> Have you opened all required ports for ldap and kerberos and other
>>> protocols in the firewall both UDP and TCP?
>>>
>>>
>>>
>>>
>>> On 19 March 2015 at 21:55, Dmitri Pal  wrote:
>>>
>>>>  On 03/19/2015 04:46 PM, Roberto Cornacchia wrote:
>>>>
>>>>  Hi,
>>>>
>>>>  This should really work like a charm, and I'm sure it is a stupid
>>>> mistake of mine if it doesn't, but I really can't find out what goes wrong.
>>>>
>>>>  Both IPA server and client are on FC21, very up to date.
>>>> Server installation (standard, with dns) worked well. Required ports
>>>> open in the firewall. Everything seems to work.
>>>>
>>>>  I di

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

The zone settings:

$ ipa dnszone-show --all
Zone name: hq.example.com.
  dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com
  Zone name: hq.example.com.
  Active zone: TRUE
  Authoritative nameserver: ipa.hq.example.com.
  Administrator e-mail address: hostmaster.hq.example.com.
  SOA serial: 1426857128
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM
krb5-self * ; grant HQ.EXAMPLE.COM krb5-self * SSHFP;
  Dynamic update: TRUE
  Allow query: any;
  Allow transfer: none;
  nsrecord: ipa.hq.example.com.
  objectclass: idnszone, top, idnsrecord

The DNS log doesn't mention anything about updates. It does contain some
errors about unreachable hosts, but that's because I had a temporary
interruption towards the gateway from the ipa server.

One thing I did after installing the IPA server is to turn off support for
ipv6, using
$ echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf
$ sysctl -p

Do you think it could have any influence?


On 20 March 2015 at 12:31, Martin Basti  wrote:

>  Hello,
>
> do you have enabled DNS dynamic updates for hq.example.zone?
> You can check it in zone settings.
>
> Are there any log entries in dns log related to nsupdate executed from a
> client?
> $ journalctl -b -u named-pkcs11
>
>
> On 20/03/15 09:53, Roberto Cornacchia wrote:
>
>  It seems so:
>
>  $ firewall-cmd --list-all
> FedoraServer (default, active)
>   interfaces: em2
>   sources:
>   services: cockpit dhcpv6-client ssh
>   ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp 464/udp
> 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp 9444/tcp 9445/tcp
> 8011/tcp 53/udp 8082/tcp
>   masquerade: no
>   forward-ports:
>   icmp-blocks:
>   rich rules:
>
>
> On 20 March 2015 at 00:53, Dmitri Pal  wrote:
>
>>  On 03/19/2015 05:04 PM, Roberto Cornacchia wrote:
>>
>>  Yes.
>>
>>  [root@meson ~]# cat /etc/resolv.conf
>> search hq.example.com
>> nameserver 192.168.0.72
>>
>>  Sorry from the short log I posted it's not visible, but that ip address
>> is the address of the ipa server (ipa.hq.example.com)
>>
>>  [root@meson ~]# dig ipa.hq.example.com
>>
>>  ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ipa.hq.example.com
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
>>
>>  ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;ipa.hq.example.com. IN A
>>
>>  ;; ANSWER SECTION:
>> ipa.hq.example.com. 1200 IN A 192.168.0.72
>>
>>  ;; AUTHORITY SECTION:
>> hq.example.com. 86400 IN NS ipa.hq.example.com.
>>
>>  ;; Query time: 1 msec
>> ;; SERVER: 192.168.0.72#53(192.168.0.72)
>> ;; WHEN: do mrt 19 22:02:04 CET 2015
>> ;; MSG SIZE  rcvd: 83
>>
>>
>>
>>  OK so you can in fact lookup the server.
>> Have you opened all required ports for ldap and kerberos and other
>> protocols in the firewall both UDP and TCP?
>>
>>
>>
>>
>> On 19 March 2015 at 21:55, Dmitri Pal  wrote:
>>
>>>  On 03/19/2015 04:46 PM, Roberto Cornacchia wrote:
>>>
>>>  Hi,
>>>
>>>  This should really work like a charm, and I'm sure it is a stupid
>>> mistake of mine if it doesn't, but I really can't find out what goes wrong.
>>>
>>>  Both IPA server and client are on FC21, very up to date.
>>> Server installation (standard, with dns) worked well. Required ports
>>> open in the firewall. Everything seems to work.
>>>
>>>  I did try to use the IPA server as a DNS (with forwarders) and NTP
>>> server from non-ipa clients, no problem.
>>> I also tried to use it as LDAP server, from a non-fedora machine (a
>>> synology). It worked well and I could see users.
>>>
>>>  When trying to enroll a client, the enrollment itself seems to
>>> succeed, but:
>>> - Unable to sync time with NTP server
>>> - Unable to update DNS
>>> - Unable to find users
>>>
>>>  I include below the short installation log (I changed the real domain
>>> into hq.example.com), and in attachment, the full log with debug on.
>>>
>>>  From the debug log, about the DNS update failure, I can see this:
>>>
>>>; Communication with 192.168.0.72#53 failed: operation canceled
>>>   could not reach a

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

It seems so:

$ firewall-cmd --list-all
FedoraServer (default, active)
  interfaces: em2
  sources:
  services: cockpit dhcpv6-client ssh
  ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp 464/udp
8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp 9444/tcp 9445/tcp
8011/tcp 53/udp 8082/tcp
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:


On 20 March 2015 at 00:53, Dmitri Pal  wrote:

>  On 03/19/2015 05:04 PM, Roberto Cornacchia wrote:
>
>  Yes.
>
>  [root@meson ~]# cat /etc/resolv.conf
> search hq.example.com
> nameserver 192.168.0.72
>
>  Sorry from the short log I posted it's not visible, but that ip address
> is the address of the ipa server (ipa.hq.example.com)
>
>  [root@meson ~]# dig ipa.hq.spinque.com
>
>  ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ipa.hq.example.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
>
>  ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ipa.hq.example.com. IN A
>
>  ;; ANSWER SECTION:
> ipa.hq.example.com. 1200 IN A 192.168.0.72
>
>  ;; AUTHORITY SECTION:
> hq.example.com. 86400 IN NS ipa.hq.example.com.
>
>  ;; Query time: 1 msec
> ;; SERVER: 192.168.0.72#53(192.168.0.72)
> ;; WHEN: do mrt 19 22:02:04 CET 2015
> ;; MSG SIZE  rcvd: 83
>
>
>
> OK so you can in fact lookup the server.
> Have you opened all required ports for ldap and kerberos and other
> protocols in the firewall both UDP and TCP?
>
>
>
>
> On 19 March 2015 at 21:55, Dmitri Pal  wrote:
>
>>  On 03/19/2015 04:46 PM, Roberto Cornacchia wrote:
>>
>>  Hi,
>>
>>  This should really work like a charm, and I'm sure it is a stupid
>> mistake of mine if it doesn't, but I really can't find out what goes wrong.
>>
>>  Both IPA server and client are on FC21, very up to date.
>> Server installation (standard, with dns) worked well. Required ports open
>> in the firewall. Everything seems to work.
>>
>>  I did try to use the IPA server as a DNS (with forwarders) and NTP
>> server from non-ipa clients, no problem.
>> I also tried to use it as LDAP server, from a non-fedora machine (a
>> synology). It worked well and I could see users.
>>
>>  When trying to enroll a client, the enrollment itself seems to succeed,
>> but:
>> - Unable to sync time with NTP server
>> - Unable to update DNS
>> - Unable to find users
>>
>>  I include below the short installation log (I changed the real domain
>> into hq.example.com), and in attachment, the full log with debug on.
>>
>>  From the debug log, about the DNS update failure, I can see this:
>>
>>; Communication with 192.168.0.72#53 failed: operation canceled
>>   could not reach any name server
>>
>>  I'm not sure what communication problem this could be, as the server
>> (which is both the IPA and the DNS servers), clearly can be reached.
>>
>>  Any idea where to look at?
>>
>>
>>  Do you have the IPA DNS server in the resolv.conf of the client?
>>
>>
>>
>>
>>  Thanks,
>> Roberto
>>
>>
>>  [root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns
>> --force-ntpd --hostname=meson.hq.example.com
>> Discovery was successful!
>> Hostname: meson.hq.example.com
>> Realm: HQ.EXAMPLE.COM
>> DNS Domain: hq.example.com
>> IPA Server: ipa.hq.example.com
>> BaseDN: dc=hq,dc=example,dc=com
>>
>>  Continue to configure the system with these values? [no]: yes
>> Synchronizing time with KDC...
>> *Unable to sync time with IPA NTP server, assuming the time is in sync.
>> Please check that 123 UDP port is opened.*
>> User authorized to enroll computers: admin
>> Password for ad...@hq.example.com:
>> Successfully retrieved CA cert
>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
>> Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
>> Valid From:  Mon Mar 16 18:44:35 2015 UTC
>> Valid Until: Fri Mar 16 18:44:35 2035 UTC
>>
>>  Enrolled in IPA realm HQ.EXAMPLE.COM
>> Created /etc/ipa/default.conf
>> New SSSD config will be created
>> Configured sudoers in /etc/nsswitch.conf
>> Configured /etc/sssd/sssd.conf
>> Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
>> trying https://ipa.hq.example.com/ipa/json
>> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
>> Forwardi

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

>
> [root@meson ~]# dig ipa.hq.spinque.com
>

 humph, sorry about the confusion, I missed one in my anonymisation step..
that would be "dig ipa.hq.example.com"
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

Yes.

[root@meson ~]# cat /etc/resolv.conf
search hq.example.com
nameserver 192.168.0.72

Sorry from the short log I posted it's not visible, but that ip address is
the address of the ipa server (ipa.hq.example.com)

[root@meson ~]# dig ipa.hq.spinque.com

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ipa.hq.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ipa.hq.example.com. IN A

;; ANSWER SECTION:
ipa.hq.example.com. 1200 IN A 192.168.0.72

;; AUTHORITY SECTION:
hq.example.com. 86400 IN NS ipa.hq.example.com.

;; Query time: 1 msec
;; SERVER: 192.168.0.72#53(192.168.0.72)
;; WHEN: do mrt 19 22:02:04 CET 2015
;; MSG SIZE  rcvd: 83


On 19 March 2015 at 21:55, Dmitri Pal  wrote:

>  On 03/19/2015 04:46 PM, Roberto Cornacchia wrote:
>
>  Hi,
>
>  This should really work like a charm, and I'm sure it is a stupid
> mistake of mine if it doesn't, but I really can't find out what goes wrong.
>
>  Both IPA server and client are on FC21, very up to date.
> Server installation (standard, with dns) worked well. Required ports open
> in the firewall. Everything seems to work.
>
>  I did try to use the IPA server as a DNS (with forwarders) and NTP
> server from non-ipa clients, no problem.
> I also tried to use it as LDAP server, from a non-fedora machine (a
> synology). It worked well and I could see users.
>
>  When trying to enroll a client, the enrollment itself seems to succeed,
> but:
> - Unable to sync time with NTP server
> - Unable to update DNS
> - Unable to find users
>
>  I include below the short installation log (I changed the real domain
> into hq.example.com), and in attachment, the full log with debug on.
>
>  From the debug log, about the DNS update failure, I can see this:
>
>; Communication with 192.168.0.72#53 failed: operation canceled
>   could not reach any name server
>
>  I'm not sure what communication problem this could be, as the server
> (which is both the IPA and the DNS servers), clearly can be reached.
>
>  Any idea where to look at?
>
>
> Do you have the IPA DNS server in the resolv.conf of the client?
>
>
>
>
>  Thanks,
> Roberto
>
>
>  [root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns
> --force-ntpd --hostname=meson.hq.example.com
> Discovery was successful!
> Hostname: meson.hq.example.com
> Realm: HQ.EXAMPLE.COM
> DNS Domain: hq.example.com
> IPA Server: ipa.hq.example.com
> BaseDN: dc=hq,dc=example,dc=com
>
>  Continue to configure the system with these values? [no]: yes
> Synchronizing time with KDC...
> *Unable to sync time with IPA NTP server, assuming the time is in sync.
> Please check that 123 UDP port is opened.*
> User authorized to enroll computers: admin
> Password for ad...@hq.example.com:
> Successfully retrieved CA cert
> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
> Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
> Valid From:  Mon Mar 16 18:44:35 2015 UTC
> Valid Until: Fri Mar 16 18:44:35 2035 UTC
>
>  Enrolled in IPA realm HQ.EXAMPLE.COM
> Created /etc/ipa/default.conf
> New SSSD config will be created
> Configured sudoers in /etc/nsswitch.conf
> Configured /etc/sssd/sssd.conf
> Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
> trying https://ipa.hq.example.com/ipa/json
> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
> Forwarding 'ca_is_enabled' to json server '
> https://ipa.hq.example.com/ipa/json'
> Systemwide CA database updated.
> Added CA certificates to the default NSS database.
> Hostname (meson.hq.example.com) not found in DNS
> *Failed to update DNS records.*
> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
> Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json'
> *Could not update DNS SSHFP records.*
> SSSD enabled
> Configured /etc/openldap/ldap.conf
> *Unable to find 'admin' user with 'getent passwd ad...@hq.example.com
> '!*
> *Unable to reliably detect configuration. Check NSS setup manually.*
> NTP enabled
> Configured /etc/ssh/ssh_config
> Configured /etc/ssh/sshd_config
> Configuring hq.example.com as NIS domain.
> Client configuration complete.
>
>
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
>
>
> --
> 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] Synology DSM5 and freeIPA

[Roberto Cornacchia]

Thanks, Jakub.


On 19 March 2015 at 21:23, Jakub Hrozek  wrote:

>
> > On 19 Mar 2015, at 21:18, Roberto Cornacchia <
> roberto.cornacc...@gmail.com> wrote:
> >
> > It's possible that I'm simply not getting the point, or that I don't
> understand the documentation correctly, but this is what I don't find clear:
> >
> > I had seen the instructions you pointed me at. These are not
> specifically about home directories.
> >
> > However, this section is:
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs
> >
> > It first suggests that automatic creation of home directories over NFS
> shares is possible: just automount /home and then use pam_oddjob_mkhomedir
> or pam_mkhomedir to create homedirs at first login.
> >
> > But then it also suggests that mounting the whole /home tree could be an
> issue, and says: "Use automount to mount only the user's home directory and
> only when the user logs in, rather than loading the entire /home tree."
> >
> > That means that automatic homedir creation is out of the game, doesn't
> it?
> >
> > That's what I find confusing. What's the recommended way?
> >
>
> It really depends on your environment. For your size, it's perfectly fine
> to NFS mount the whole /home tree and be done with it. Don't optimize
> prematurely :-)
>
> >
> >
> > On 19 March 2015 at 20:49, Dmitri Pal  wrote:
> > On 03/19/2015 02:46 PM, Roberto Cornacchia wrote:
> >> Hi Dmitri,
> >>
> >> I do realise my question is borderline and I accept that it is
> considered off-topic.
> >>
> >> I did post it here because I believe it's not *only* about NFS, but
> also about its interaction with freeIPA. The issue of NFS home and in
> particular about their creation is touched in all the links I posted (all
> about freeIPA) and never really answered.
> >>
> >
> > This is what documented and recommended:
> >
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs
> >
> > RHEL6 has a similar chapter in its doc set though books have changed
> significantly between 6 and 7.
> >
> > I do not see any chicken and egg problem there.
> > The instructions show how to create home dirs on the first login.
> >
> > It mounts the volume and then creates dirs on it as users log in if they
> are not already there.
> >
> > It is unclear what problem you see with doing it the way it is
> recommended.
> >
> >
> >
> >> Best,
> >> Roberto
> >>
> >> On 19 March 2015 at 19:36, Dmitri Pal  wrote:
> >> On 03/19/2015 05:29 AM, Roberto Cornacchia wrote:
> >>> On 6 March 2015 at 11:15, Martin Kosek  wrote:
> >>> On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:
> >>> Hi there,
> >>>
> >>> I'm planning to deploy freeIPA on our lan.
> >>> It's small-ish and completely based on FC21, so I expect everything to
> work
> >>> like a charm.
> >>>
> >>> Except one detail. We have Synology NAS station, which uses DSM 5.0.
> >>> The ideal plan is to use it as host for shared NFS home dirs once we
> switch our
> >>> desktops to freeIPA.
> >>>
> >>> Great!
> >>>
> >>>
> >>> Hello,
> >>>
> >>> The first thing I'm struggling  with is to find the correct approach
> about NFS home dirs.
> >>> The ideal setting would be:
> >>> - home dirs on the NAS
> >>> - IPA manages automount maps
> >>> - home dirs are created automatically at first login
> >>>
> >>> The documentation I could find on these topics includes only
> not-so-recent pages (anything I missed?):
> >>>
> >>> http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA
> >>>
> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html
> >>>
> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories
> >>>
> http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/
> >>>
> >>> Now, I admit I don't have much experience with setting up NFS homes,
> with or without freeIPA, so trying to get this done correctly in the
> context of freeIPA and without clear howtos isn&#x

[Freeipa-users] ipa-client-install failure

[Roberto Cornacchia]

Hi,

This should really work like a charm, and I'm sure it is a stupid mistake
of mine if it doesn't, but I really can't find out what goes wrong.

Both IPA server and client are on FC21, very up to date.
Server installation (standard, with dns) worked well. Required ports open
in the firewall. Everything seems to work.

I did try to use the IPA server as a DNS (with forwarders) and NTP server
from non-ipa clients, no problem.
I also tried to use it as LDAP server, from a non-fedora machine (a
synology). It worked well and I could see users.

When trying to enroll a client, the enrollment itself seems to succeed, but:
- Unable to sync time with NTP server
- Unable to update DNS
- Unable to find users

I include below the short installation log (I changed the real domain into
hq.example.com), and in attachment, the full log with debug on.

>From the debug log, about the DNS update failure, I can see this:

  ; Communication with 192.168.0.72#53 failed: operation canceled
  could not reach any name server

I'm not sure what communication problem this could be, as the server (which
is both the IPA and the DNS servers), clearly can be reached.

Any idea where to look at?

Thanks,
Roberto


[root@meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd
--hostname=meson.hq.example.com
Discovery was successful!
Hostname: meson.hq.example.com
Realm: HQ.EXAMPLE.COM
DNS Domain: hq.example.com
IPA Server: ipa.hq.example.com
BaseDN: dc=hq,dc=example,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time with KDC...
*Unable to sync time with IPA NTP server, assuming the time is in sync.
Please check that 123 UDP port is opened.*
User authorized to enroll computers: admin
Password for ad...@hq.example.com:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM
Issuer:  CN=Certificate Authority,O=HQ.EXAMPLE.COM
Valid From:  Mon Mar 16 18:44:35 2015 UTC
Valid Until: Fri Mar 16 18:44:35 2035 UTC

Enrolled in IPA realm HQ.EXAMPLE.COM
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm HQ.EXAMPLE.COM
trying https://ipa.hq.example.com/ipa/json
Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json'
Forwarding 'ca_is_enabled' to json server '
https://ipa.hq.example.com/ipa/json'
Systemwide CA database updated.
Added CA certificates to the default NSS database.
Hostname (meson.hq.example.com) not found in DNS
*Failed to update DNS records.*
Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json'
*Could not update DNS SSHFP records.*
SSSD enabled
Configured /etc/openldap/ldap.conf
*Unable to find 'admin' user with 'getent passwd ad...@hq.example.com
'!*
*Unable to reliably detect configuration. Check NSS setup manually.*
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring hq.example.com as NIS domain.
Client configuration complete.
/usr/sbin/ipa-client-install was invoked with options: {'domain': None, 'force': False, 'krb5_offline_passwords': True, 'configure_firefox': False, 'primary': False, 'conf_sudo': True, 'force_ntpd': True, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'on_master': False, 'no_nisdomain': False, 'nisdomain': None, 'ntp_server': None, 'principal': None, 'keytab': None, 'hostname': 'meson.hq.example.com', 'request_cert': False, 'no_ac': False, 'unattended': None, 'location': None, 'sssd': True, 'trust_sshfp': True, 'dns_updates': True, 'realm_name': None, 'conf_ssh': True, 'force_join': False, 'firefox_dir': None, 'ca_cert_file': None, 'server': None, 'prompt_password': False, 'permit': False, 'debug': True, 'preserve_sssd': False, 'mkhomedir': True, 'uninstall': False}
missing options might be asked for interactively later
IPA version 4.1.3-2.fc21
Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=None, servers=None, hostname=meson.hq.example.com
Start searching for LDAP SRV record in "hq.example.com" (domain of the hostname) and its sub-domains
Search DNS for SRV record of _ldap._tcp.hq.example.com
DNS record found: 0 100 389 ipa.hq.example.com.
[Kerberos realm search]
Search DNS for TXT record of _kerberos.hq.example.com
DNS record found: "HQ.EXAMPLE.COM"
Search DNS for SRV record of _kerberos._udp.hq.example.com
DNS record found: 0 100 88 ipa.hq.example.com.
[LDAP server check]
Verifying that ipa.hq.example.com (realm HQ.EXAMPLE.COM) is an IPA server
Init LDAP connection to: ipa.hq.example.com
Search LDAP server for IPA base DN
Check if naming context 'dc=hq,dc=example,dc=com' is for IPA

Re: [Freeipa-users] Synology DSM5 and freeIPA

[Roberto Cornacchia]

It's possible that I'm simply not getting the point, or that I don't
understand the documentation correctly, but this is what I don't find clear:

I had seen the instructions you pointed me at. These are not specifically
about home directories.

However, this section is:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs


It first suggests that automatic creation of home directories over NFS
shares is possible: just automount /home and then use pam_oddjob_mkhomedir
or pam_mkhomedir to create homedirs at first login.

But then it also suggests that mounting the whole /home tree could be an
issue, and says: "*Use automount to mount only the user's home directory
and only when the user logs in, rather than loading the entire /home tree."*

That means that automatic homedir creation is out of the game, doesn't it?

That's what I find confusing. What's the recommended way?



On 19 March 2015 at 20:49, Dmitri Pal  wrote:

>  On 03/19/2015 02:46 PM, Roberto Cornacchia wrote:
>
> Hi Dmitri,
>
>  I do realise my question is borderline and I accept that it is
> considered off-topic.
>
>  I did post it here because I believe it's not *only* about NFS, but also
> about its interaction with freeIPA. The issue of NFS home and in particular
> about their creation is touched in all the links I posted (all about
> freeIPA) and never really answered.
>
>
> This is what documented and recommended:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs
>
> RHEL6 has a similar chapter in its doc set though books have changed
> significantly between 6 and 7.
>
> I do not see any chicken and egg problem there.
> The instructions show how to create home dirs on the first login.
>
> It mounts the volume and then creates dirs on it as users log in if they
> are not already there.
>
> It is unclear what problem you see with doing it the way it is recommended.
>
>
>
>  Best,
> Roberto
>
> On 19 March 2015 at 19:36, Dmitri Pal  wrote:
>
>>   On 03/19/2015 05:29 AM, Roberto Cornacchia wrote:
>>
>>  On 6 March 2015 at 11:15, Martin Kosek  wrote:
>>
>>> On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:
>>>
>>>> Hi there,
>>>>
>>>> I'm planning to deploy freeIPA on our lan.
>>>> It's small-ish and completely based on FC21, so I expect everything to
>>>> work
>>>> like a charm.
>>>>
>>>> Except one detail. We have Synology NAS station, which uses DSM 5.0.
>>>> The ideal plan is to use it as host for shared NFS home dirs once we
>>>> switch our
>>>> desktops to freeIPA.
>>>>
>>>
>>>  Great!
>>>
>>>>
>>>>
>>  Hello,
>>
>>  The first thing I'm struggling  with is to find the correct approach
>> about NFS home dirs.
>> The ideal setting would be:
>> - home dirs on the NAS
>> - IPA manages automount maps
>> - home dirs are created automatically at first login
>>
>>  The documentation I could find on these topics includes only
>> not-so-recent pages (anything I missed?):
>>
>>   http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA
>>
>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html
>>
>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories
>>
>> http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/
>>
>>  Now, I admit I don't have much experience with setting up NFS homes,
>> with or without freeIPA, so trying to get this done correctly in the
>> context of freeIPA and without clear howtos isn't very easy, but I'm
>> willing to get my hands dirty.
>>
>>  The first problem I struggle with is on the correct approach.
>> From the documentation above, I understand that there is a bit of a
>> chicken-egg problem about the creation of home dirs.
>> On the one hand, it would be optimal to have automount maps to load only
>> single home dirs on demand, rather than the entire /home tree.
>> On the other hand, if the /home tree is not available, then creating
>> /home/user1 dir automatically isn't really possible.
>>
>>  Just mounting the whole /home tree would make things easier, but I
>> don't have a feeling of when it starts to become a performance issue
>> (assuming recent hardware and up to 

Re: [Freeipa-users] Synology DSM5 and freeIPA

[Roberto Cornacchia]

Hi Dmitri,

I do realise my question is borderline and I accept that it is considered
off-topic.

I did post it here because I believe it's not *only* about NFS, but also
about its interaction with freeIPA. The issue of NFS home and in particular
about their creation is touched in all the links I posted (all about
freeIPA) and never really answered.

Best,
Roberto

On 19 March 2015 at 19:36, Dmitri Pal  wrote:

>  On 03/19/2015 05:29 AM, Roberto Cornacchia wrote:
>
>  On 6 March 2015 at 11:15, Martin Kosek  wrote:
>
>> On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:
>>
>>> Hi there,
>>>
>>> I'm planning to deploy freeIPA on our lan.
>>> It's small-ish and completely based on FC21, so I expect everything to
>>> work
>>> like a charm.
>>>
>>> Except one detail. We have Synology NAS station, which uses DSM 5.0.
>>> The ideal plan is to use it as host for shared NFS home dirs once we
>>> switch our
>>> desktops to freeIPA.
>>>
>>
>>  Great!
>>
>>>
>>>
>  Hello,
>
>  The first thing I'm struggling  with is to find the correct approach
> about NFS home dirs.
> The ideal setting would be:
> - home dirs on the NAS
> - IPA manages automount maps
> - home dirs are created automatically at first login
>
>  The documentation I could find on these topics includes only
> not-so-recent pages (anything I missed?):
>
>   http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA
>
> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html
>
> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories
>  http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/
>
>  Now, I admit I don't have much experience with setting up NFS homes,
> with or without freeIPA, so trying to get this done correctly in the
> context of freeIPA and without clear howtos isn't very easy, but I'm
> willing to get my hands dirty.
>
>  The first problem I struggle with is on the correct approach.
> From the documentation above, I understand that there is a bit of a
> chicken-egg problem about the creation of home dirs.
> On the one hand, it would be optimal to have automount maps to load only
> single home dirs on demand, rather than the entire /home tree.
> On the other hand, if the /home tree is not available, then creating
> /home/user1 dir automatically isn't really possible.
>
>  Just mounting the whole /home tree would make things easier, but I don't
> have a feeling of when it starts to become a performance issue (assuming
> recent hardware and up to date software). 10 users? 50? 100? 500? No idea.
> The realm I'm dealing with at the moment is in the range of 5-10 users and
> probably won't be larger than 50 in the next few years (and if it will, it
> means things are going well, so what the heck ;)
> Also true that, with such few users, I could just create the homedirs
> manually when needed (this is not an organisation where many users come and
> go) and just mount the individually.
> Any tips about this?
>
>  Best, Roberto
>
>
>
>
>  Some of these questions are really outside the scope of this list.
> You might consider asking them on the NFS list.
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
>
>
> --
> 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] Synology DSM5 and freeIPA

[Roberto Cornacchia]

On 6 March 2015 at 11:15, Martin Kosek  wrote:

> On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:
>
>> Hi there,
>>
>> I'm planning to deploy freeIPA on our lan.
>> It's small-ish and completely based on FC21, so I expect everything to
>> work
>> like a charm.
>>
>> Except one detail. We have Synology NAS station, which uses DSM 5.0.
>> The ideal plan is to use it as host for shared NFS home dirs once we
>> switch our
>> desktops to freeIPA.
>>
>
> Great!
>
>>
>>
Hello,

The first thing I'm struggling  with is to find the correct approach about
NFS home dirs.
The ideal setting would be:
- home dirs on the NAS
- IPA manages automount maps
- home dirs are created automatically at first login

The documentation I could find on these topics includes only not-so-recent
pages (anything I missed?):

http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html
http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories
http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/

Now, I admit I don't have much experience with setting up NFS homes, with
or without freeIPA, so trying to get this done correctly in the context of
freeIPA and without clear howtos isn't very easy, but I'm willing to get my
hands dirty.

The first problem I struggle with is on the correct approach.
>From the documentation above, I understand that there is a bit of a
chicken-egg problem about the creation of home dirs.
On the one hand, it would be optimal to have automount maps to load only
single home dirs on demand, rather than the entire /home tree.
On the other hand, if the /home tree is not available, then creating
/home/user1 dir automatically isn't really possible.

Just mounting the whole /home tree would make things easier, but I don't
have a feeling of when it starts to become a performance issue (assuming
recent hardware and up to date software). 10 users? 50? 100? 500? No idea.
The realm I'm dealing with at the moment is in the range of 5-10 users and
probably won't be larger than 50 in the next few years (and if it will, it
means things are going well, so what the heck ;)
Also true that, with such few users, I could just create the homedirs
manually when needed (this is not an organisation where many users come and
go) and just mount the individually.
Any tips about this?

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

Re: [Freeipa-users] DNS forwarders

[Roberto Cornacchia]

I see. Peter, Martin, thanks for the explanation. My worry was that
something went wrong in my reinstallation, glad to hear it is not the case.

Roberto
On 17 Mar 2015 14:51, "Petr Spacek"  wrote:

> On 17.3.2015 14:06, Martin Basti wrote:
> > On 17/03/15 13:32, Roberto Cornacchia wrote:
> >> Hi there,
> >>
> >> I've just installed freeIPA on a FC21 server and trying to perform some
> >> sanity checks.
> >>
> >> A first puzzle for me is: I have some DNS forwarders, which I selected
> >> during installation.
> >> They do work and they do appear in /etc/named.conf
> >>
> >>   forward first;
> >> forwarders {
> >> 217.21.244.7;
> >> 217.21.244.66;
> >> 8.8.8.8;
> >> 8.8.4.4;
> >> };
> >>
> >> However, I don't see them as DNS forwarders in IPA? Should I see them?
> >>
> >> Roberto
> >>
> >>
> > Hello,
> >
> > if you want to see them in IPA, you must add those forwarders with IPA
> command
> >
> > ipa dnsconfig-mod --forwarder=8.8.4.4 --forwarder=8.8.8.8 ...
> > or using webUI
> >
> > This setting will override configuration of forwarders in named.conf.
> >
> > I don't know if there are some historical reasons to configure
> forwarders only
> > in named.conf during installation, do you know Petr?
>
> This is done for practical purposes. In cases where you have multiple IPA
> servers scatted across the globe you most likely do not want to use the
> same
> set of forwarders for all IPA DNS servers - usually you want to use nearest
> forwarder possible.
>
> 'ipa dnsconfig' is global for the whole cluster, /etc/named.conf is local
> for
> that particular server.
>
> It would be nice to move per-server configuration to LDAP to make it
> available
> via IPA user interface but up to know it did not get priority.
>
> --
> Petr^2 Spacek
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] DNS forwarders

[Roberto Cornacchia]

Hi there,

I've just installed freeIPA on a FC21 server and trying to perform some
sanity checks.

A first puzzle for me is: I have some DNS forwarders, which I selected
during installation.
They do work and they do appear in /etc/named.conf

  forward first;
forwarders {
217.21.244.7;
217.21.244.66;
8.8.8.8;
8.8.4.4;
};

However, I don't see them as DNS forwarders in IPA? Should I see them?

Roberto
-- 
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] Synology DSM5 and freeIPA

[Roberto Cornacchia]

Hi there,

I'm planning to deploy freeIPA on our lan.
It's small-ish and completely based on FC21, so I expect everything to work
like a charm.

Except one detail. We have Synology NAS station, which uses DSM 5.0.
The ideal plan is to use it as host for shared NFS home dirs once we switch
our desktops to freeIPA.

I've already tried on a VirtualBox replica of our lan how to configure the
Synology station against freeIPA.
LDAP enrolling worked, and I created a srv entry in the freeIPA dns, but I
didn't go further than that.

SSSD does not seem to exist for DSM 5. What are the implications? Can it do
without? I understood SSSD works as a caching system, so that the machine
keeps working when freeIPA is unavailable. Does it have any other vital
role?

Thanks for your input.

Roberto

PS. This mailing list is pleasantly active. Keep up the good work!
-- 
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] basic question on DNS configuration

[Roberto Cornacchia]

Thank you Craig and Martin for your useful input.

You both definitely recommend not to use example.com for the internal IPA
DNS.

I was in any case going to avoid .local suffix and any invented top-level
domain, after some reading on this topic.

Using a subdomain like internal.example.com seems reasonable.
I was under the impression that the freeIPA domain needed to be a top-level
one, but maybe I was wrong here? Can I still keep example.com outside and
have freeIPA manage internal.example.com?



On 4 February 2015 at 10:34, Martin Basti  wrote:

>  On 03/02/15 16:52, Craig White wrote:
>
>  *From:* freeipa-users-boun...@redhat.com [
> mailto:freeipa-users-boun...@redhat.com ]
> *On Behalf Of *Roberto Cornacchia
> *Sent:* Tuesday, February 03, 2015 5:20 AM
> *To:* freeipa-users@redhat.com
> *Subject:* [Freeipa-users] basic question on DNS configuration
>
>
>
> Hi guys,
>
>
>
> I can't wait to get freeIPA installed in our small enterprise, but I'd
> first like to get a couple of basic things straight.
>
>
>
> My first doubt is about the DNS configuration. Currently, we use a setting
> that I guess is rather common for small enterprises:
>
>
>
> We own an example.com domain which is managed by the DNS of an external
> provider.
>
>
>
> A couple of subdomains point to public IP addresses outside our local
> network (e.g. www.example.com is hosted at our internet provider,
> server1.example.com points at a server hosted in a datacenter, etc).
>
>
>
> All the remaining subdomain (*.example.com) point at one IP which
> corresponds to our local router.
>
> Then we use some simple forwarding rules to forward on to machines that
> are behind the router (service1.example.com, desktop1.example.com,
> desktop2.example.com, etc).
>
>
>
> Internally, because the enterprise is rather small, we are not using a
> DNS, but simply /etc/hosts files on each machine. When they can't resolve
> whatever.example.com, then the request goes to the external DNS.
>
>
>
> (sorry about the long-ish background information, probably this
> configuration is commonly named somehow, but I don't know how)
>
>
>
> Now, a first simple question for you guys would be:
>
> When installing freeIPA, with DNS, is the network configuration above
> still advisable? Can there be any problem? Or should I rather use a
> different domain for the internal network (I would really NOT like this
> option, but I'm very interested to know why I should, if that is the case).
>
>
>
>
>
> A second basic question is:
>
> Would you see any potential problem in installing freeIPA on a FC21 Server
> which currently hosts Atlassian Jira + Atlassian Stash (therefore git
> repositories) + the required mysql databases?
>
> My guess would be that they would not interfere, as:
>
> - httpd (and related ports) is currently unused)
>
> - Both Jira and Stash use thier own tomcat installation on custom ports
>
> - mysql shouldn't be a problem?
>
> - The machine isn't overloaded at all (4-5 developers use those services)
>
>
>
> Am I overlooking something? Obviously I'd rather have a dedicated freeIPA
> server, but if the above mentioned coexistence isn't a problem, then this
> would be more cost-effective.
>
>
>
> Thank you very much for your help, I'm looking forward to this upgrade.
>
> Roberto
>
> I would recommend that you create a ‘local’ domain for your internal LAN
> though you certainly can use your domain name for both the internal LAN and
> the external world. Obviously you would have to create ‘manual’ entries in
> DNS for the external servers (like www.example.com) so your internal LAN
> systems can resolve it. If you have a ‘local’ domain for your internal LAN,
> there aren’t name collisions, no need to manually maintain DNS entries for
> off-LAN servers and no confusion of essentially faking your LAN systems
> into believing that the IPA server is authoritative for example.com
> domain when the rest of the world thinks otherwise. The choice is yours.
>
>
>
> As for using F21 – you get the latest version of FreeIPA which is
> something I wish I had here.
>
>
>
> Git / Stash / Jira represent a fairly hefty memory footprint even if there
> isn’t that much CPU load. If you have the RAM and cpu cores to handle
> tossing FreeIPA onto the stack, go for it. You probably will want a replica
> too as the replica keeps your LAN running if the primary server is
> unavailable for whatever reason and it minimizes backup needs substantially.
>
>
>
> Craig
>
>
>
>
>  Hello,
>
> For using 'local.' domain please read following message, to a

[Freeipa-users] basic question on DNS configuration

[Roberto Cornacchia]

Hi guys,

I can't wait to get freeIPA installed in our small enterprise, but I'd
first like to get a couple of basic things straight.

My first doubt is about the DNS configuration. Currently, we use a setting
that I guess is rather common for small enterprises:

We own an example.com domain which is managed by the DNS of an external
provider.

A couple of subdomains point to public IP addresses outside our local
network (e.g. www.example.com is hosted at our internet provider,
server1.example.com points at a server hosted in a datacenter, etc).

All the remaining subdomain (*.example.com) point at one IP which
corresponds to our local router.
Then we use some simple forwarding rules to forward on to machines that are
behind the router (service1.example.com, desktop1.example.com,
desktop2.example.com, etc).

Internally, because the enterprise is rather small, we are not using a DNS,
but simply /etc/hosts files on each machine. When they can't resolve
whatever.example.com, then the request goes to the external DNS.

(sorry about the long-ish background information, probably this
configuration is commonly named somehow, but I don't know how)

Now, a first simple question for you guys would be:
When installing freeIPA, with DNS, is the network configuration above still
advisable? Can there be any problem? Or should I rather use a different
domain for the internal network (I would really NOT like this option, but
I'm very interested to know why I should, if that is the case).


A second basic question is:
Would you see any potential problem in installing freeIPA on a FC21 Server
which currently hosts Atlassian Jira + Atlassian Stash (therefore git
repositories) + the required mysql databases?
My guess would be that they would not interfere, as:
- httpd (and related ports) is currently unused)
- Both Jira and Stash use thier own tomcat installation on custom ports
- mysql shouldn't be a problem?
- The machine isn't overloaded at all (4-5 developers use those services)

Am I overlooking something? Obviously I'd rather have a dedicated freeIPA
server, but if the above mentioned coexistence isn't a problem, then this
would be more cost-effective.

Thank you very much for your help, I'm looking forward to this upgrade.
Roberto
-- 
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