fail joining to a freeipa server with ipa-client-install

Bug #997990 reported by pasqual milvaques
54
This bug affects 9 people
Affects Status Importance Assigned to Milestone
FreeIPA packaging
Confirmed
Unknown
freeipa (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I try to join a freeipa domain and it seems there is some problem with the tls negotiacion. this is the log:
pasqual@ubuntuprovesfreeipa:~$ sudo ipa-client-install -d --enable-dns-updates
[sudo] password for pasqual:
root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': None, 'uninstall': False, 'force': False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname': None, 'permit': False, 'server': None, 'prompt_password': False, 'mkhomedir': False, 'dns_updates': True, 'preserve_sssd': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'realm_name': None, 'unattended': None, 'principal': None}
root : DEBUG missing options might be asked for interactively later

root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
root : DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
root : DEBUG [ipadnssearchldap(linux.gva.es)]
root : DEBUG [ipadnssearchldap(gva.es)]
root : DEBUG [ipadnssearchldap(es)]
root : DEBUG [ipadnssearchldap(linux.gva.es)]
root : DEBUG [ipadnssearchldap(gva.es)]
root : DEBUG [ipadnssearchldap(es)]
root : DEBUG Domain not found
DNS discovery failed to determine your DNS domain
Provide the domain name of your IPA server (ex: example.com): linux.gva.es
root : DEBUG will use domain: linux.gva.es

root : DEBUG [ipadnssearchldap]
root : DEBUG IPA Server not found
DNS discovery failed to find the IPA Server
Provide your IPA server name (ex: ipa.example.com): freeipaserver.linux.gva.es
root : DEBUG will use server: freeipaserver.linux.gva.es

root : DEBUG [ipadnssearchkrb]
root : DEBUG [ipacheckldap]
root : DEBUG args=/usr/bin/wget -O /tmp/tmpWptXwb/ca.crt -T 15 -t 2 http://freeipaserver.linux.gva.es/ipa/config/ca.crt
root : DEBUG stdout=
root : DEBUG stderr=--2012-05-11 12:06:09-- http://freeipaserver.linux.gva.es/ipa/config/ca.crt
Resolent freeipaserver.linux.gva.es (freeipaserver.linux.gva.es)... 192.168.222.99
S'està connectant a freeipaserver.linux.gva.es (freeipaserver.linux.gva.es)|192.168.222.99|:80... conectat.
HTTP: Petició enviada, esperant resposta... 200 OK
Longitud: 1325 (1.3K) [application/x-x509-ca-cert]
S'està desant a: «/tmp/tmpWptXwb/ca.crt»

     0K . 100% 38.4M=0s

2012-05-11 12:06:09 (38.4 MB/s) - s'ha desat «/tmp/tmpWptXwb/ca.crt» [1325/1325]

root : DEBUG Init ldap with: ldap://freeipaserver.linux.gva.es:389
root : ERROR LDAP Error: Connect error: A TLS packet with unexpected length was received.
Failed to verify that freeipaserver.linux.gva.es is an IPA Server.
This may mean that the remote server is not up or is not reachable
due to network or firewall settings.
Installation failed. Rolling back changes.
IPA client is not configured on this system.
pasqual@ubuntuprovesfreeipa:~$

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: freeipa-client 2.1.4-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic-pae 3.2.14
Uname: Linux 3.2.0-24-generic-pae i686
ApportVersion: 2.0.1-0ubuntu7
Architecture: i386
Date: Fri May 11 12:07:16 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release i386 (20120423)
SourcePackage: freeipa
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :
Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

trying to connect with ldapseach gives the same error:

pasqual@ubuntuprovesfreeipa:~$ ldapsearch -x -b -v -d8 "dc=linux,dc=gva,dc=es" -H ldaps://freeipaserver.linux.gva.es "objectClass=*"
TLS: can't connect: A TLS packet with unexpected length was received..
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
pasqual@ubuntuprovesfreeipa:~$

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :
Download full text (3.3 KiB)

the problem could be also reproduced with the gnutls-cli command. it seeems that's launching the handshake in an incompatible manner with the server.
the same comman from a centos box works (2.8.5 version of gnutls-cli). in the ubuntu box is version 2.12.14

root@ubuntuprovesfreeipa:/etc/ldap# gnutls-cli -d 4 -p 636 freeipaserver.linux.gva.es
Resolving 'freeipaserver.linux.gva.es'...
Connecting to '192.168.222.99:636'...
|<4>| REC[0x9b5bf68]: Allocating epoch #0
|<2>| ASSERT: gnutls_constate.c:695
|<4>| REC[0x9b5bf68]: Allocating epoch #1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x9b5bf68]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<2>| EXT[0x9b5bf68]: Sending extension SERVER NAME (31 bytes)
|<2>| EXT[0x9b5bf68]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<2>| EXT[0x9b5bf68]: Sending extension SESSION TICKET (0 bytes)
|<2>| EXT[SIGA]: sent signature algo (4.2) DSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (4.1) RSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (2.1) RSA-SHA1
|<2>| EXT[SIGA]: sent signature algo (2.2) DSA-SHA1
|<2>| EXT[0x9b5bf68]: Sending extension SIGNATURE ALGORITHMS (10 bytes)
|<3>| HSK[0x9b5bf68]: CLIENT HELLO was sent [151 bytes]
|<4>| REC[0x9b5bf68]: Sending Packet[0] Handshake(22) with length: 151
|<4>| REC[0x9b5bf68]: Sent Packet[1] Handshake(22) with length: 156
|<2>| ASSERT: gnutls_buffers.c:640
|<2>| ASSERT: gnutls_record.c:969
|<2>| ASSERT: gnutls_handshake.c:2762
*** Fatal error: A TLS packet with unexpected length was received.
|<4>| REC: Sending Alert[2|22] - Record overflow
|<4>| REC[0x9b5bf68]: Sending Packet[1] Alert(21) with length: 2
|<4>| REC[0x9b5bf68]: Sent Packet[2] Alert(21) with length: 7
*...

Read more...

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

I'have download and compiled some versions of gnutls and this is the result:
gnutls-2.8.5: works
gnutls-2.12.19: fail
gnutls-3.0.19: fail

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Yes, this is likely a bug in NSS on the server. You can make it work by enabling SSL v3 on the server:

- shut dirsrv down
- edit /etc/dirsrv/slapd-FOO/dse.ldif:
  - search for 'nsSSL3:', change the value to 'on'
  - save the file
- start dirsrv

the next time ipa-client-install should work.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

gnutls has changed but it's apparently doing the right thing, the details at

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663127

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

I have enabled ssl3 in the server with this order:
ldapmodify -D "cn=directory manager" -W -p 389 -h localhost -x

dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3
nsSSL3: on

exit

restarted the server with ipactl restart and now the command ipa-client-install initiates the joining to the domain but there is a new problem, the command crashes with this lines:
New SSSD config will be created.
root : INFO New SSSD config will be created
Configured /etc/sssd/sssd.conf
root : DEBUG args=/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i /etc/ipa/ca.crt
root : DEBUG stdout=
root : DEBUG stderr=certutil: function failed: security library: bad database.

Traceback (most recent call last):
  File "/usr/sbin/ipa-client-install", line 1292, in <module>
    sys.exit(main())
  File "/usr/sbin/ipa-client-install", line 1279, in main
    rval = install(options, env, fstore, statestore)
  File "/usr/sbin/ipa-client-install", line 1124, in install
    run(["/usr/bin/certutil", "-A", "-d", "/etc/pki/nssdb", "-n", "IPA CA", "-t", "CT,C,C", "-a", "-i", "/etc/ipa/ca.crt"])
  File "/usr/lib/python2.7/dist-packages/ipapython/ipautil.py", line 273, in run
    raise CalledProcessError(p.returncode, args)
subprocess.CalledProcessError: Command '/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i /etc/ipa/ca.crt' returned non-zero exit status 255
pasqual@ubuntuprovesfreeipa:~$

the problem is that the system nss database doesn't exist in a new system. I can create it with the commands:
mkdir -p /etc/pki/nssdb
certutil -N -d /etc/pki/nssdb

but asks for a password. there are some obscure referencies about using a password file called pwdfile.txt that resides in the server but I'm not sure with what to do now. any idea?

thanks

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

I have found this messages about problems running freipa in ubuntu:
https://www.redhat.com/archives/freeipa-devel/2011-September/msg00407.html
https://www.redhat.com/archives/freeipa-devel/2011-September/msg00408.html

and this ticket:
https://fedorahosted.org/freeipa/ticket/1887

I created the nss database with null password, run an ipa-client-install --uninstall and tried to join the domain only to find a problem configuring ntp because the installation script tries to modify a sysconfig file that only exists in redhat systems:
root : DEBUG Backing up system configuration file '/etc/ntp.conf'
root : DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index'
root : DEBUG Backing up system configuration file '/etc/sysconfig/ntpd'
root : DEBUG -> Not backing up - '/etc/sysconfig/ntpd' doesn't exist
Traceback (most recent call last):
  File "/usr/sbin/ipa-client-install", line 1292, in <module>
    sys.exit(main())
  File "/usr/sbin/ipa-client-install", line 1279, in main
    rval = install(options, env, fstore, statestore)
  File "/usr/sbin/ipa-client-install", line 1247, in install
    ipaclient.ntpconf.config_ntp(ntp_server, fstore, statestore)
  File "/usr/lib/python2.7/dist-packages/ipaclient/ntpconf.py", line 127, in config_ntp
    __write_config(path_ntp_sysconfig, ntp_sysconfig)
  File "/usr/lib/python2.7/dist-packages/ipaclient/ntpconf.py", line 94, in __write_config
    fd = open(path, "w")
IOError: [Errno 2] No such file or directory: '/etc/sysconfig/ntpd'
pasqual@ubuntuprovesfreeipa:~$

as a workaround I comment this lines in /usr/lib/python2.7/dist-packages/ipaclient/ntpconf.py :
__backup_config(path_ntp_sysconfig, fstore)
__write_config(path_ntp_sysconfig, ntp_sysconfig)
ipaservices.restore_context(path_ntp_sysconfig)

after that the install can finnish correctly although there are some minor errors in the log (which I attach). I'm now testing if the system is functional (it has bad look)

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :
Changed in freeipa:
status: Unknown → New
Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

the system doesn't seem to be functional. the install phase asks to input the equivalent of a redhat command for the ubuntu platform:
Would run on a Red Hat platform: /usr/sbin/authconfig --enablesssdauth --enablemkhomedir --update --enablesssd
Please do the corresponding changes manually and press Enter:

this is quite obscure if you don't have a good knowledge of both platforms.
this package needs more work to be really functional, the debian.py file has implemented some of the personalization for the ubuntu platform but needs more work to avoid all this pain

thanks

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

What do you mean by "doesn't seem to be functional"? What doesn't work? It's working fine here, though the install script is missing some cleanups as you've noticed.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

ah, if you mean the comment "would run.." it's just informational. SSSD is already enabled, and pam is otherwise configured, but there's no pam-auth-update config for pam_mkhomedir.. probably should just change the text, or drop it.

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

for the moment these things doesn't work:
-gdm integration: I intend to use this for normal users who will use ubuntu as desktop machines so this is a must
-the first time I tried to use a domain user I receive an error when trying to change the password, in /var/log/auth.log:
May 14 14:03:47 ubuntuprovesfreeipa su[2098]: pam_chauthtok: Authentication token manipulation error
-I dont't know how to do the authconfig in the ubuntu system, this can be the cause of the anterior problem but I can't be sure (the --mkhomedir option seems not to be working for this also).

all the configuration problems encountered will make the managers of my organization very cautious about using this as it's a dangerous step to change a microsoft windows infrastructure which is expensive but works for this one which is free&open but seems to need more polishing before to be enterprise ready. perhaps I can give a hand but is a question of priorities which is not decided by me

I will try to test freeipa with fedora/centos but my organization uses an ubuntu derivative so it's very difficult that they change they choosen distribution only for this

thanks

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

The password change not working is a bug in the libpam-sss pam config file, either install libpam-cracklib or drop 'use_authtok' from the /usr/share/pam-configs/sss file (from the Password line). Dropping the option will be provided as an update to 12.04 at a later date.

I don't know what you mean by 'gdm integration'. It uses the same pam config as everything else, and should just work.

Authconfig is a redhat specific tool. Pam_mkhomedir is useful only if you don't have networked homedirectories, and you can add it to the pam stack quite easily (there should be a bug about adding it to the default config).

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

I have removed use_authtok from the sss file but there must be something wrong because I can't still change the password. I have followed the instructions here https://fedoraproject.org/wiki/How_to_debug_SSSD_problems to enable sssd_pam debug and it seems to be doing the same thing:
(Tue May 15 10:31:07 2012) [sssd[pam]] [accept_fd_handler] (0x0100): Client connected!
(Tue May 15 10:31:07 2012) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3].
(Tue May 15 10:31:07 2012) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3].
(Tue May 15 10:31:07 2012) [sssd[pam]] [pam_cmd_chauthtok_prelim] (0x0100): entering pam_cmd_chauthtok_prelim
(Tue May 15 10:31:07 2012) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_CHAUTHTOK_PRELIM
(Tue May 15 10:31:07 2012) [sssd[pam]] [pam_print_data] (0x0100): domain: (null)
(Tue May 15 10:31:07 2012) [sssd[pam]] [pam_print_data] (0x0100): user: pmilvaques

perhaps some other option must be changed in another place. installing libpam-cracklib didn't solve the problem also

the gdm integration problem was that when I tried to login to the system de display manager didn't let me choose other user apart from the local users of the system. this seems to be an ubuntu design decision which can be changed following the steps indicated here:
http://www.tejasbarot.com/2012/04/30/howto-other-login-option-on-login-screen-ubuntu-12-04-lts-precise-pangolin/

it would be nice that when joining a domain this would be automatically changed because it's a bit obscure to find and if not done only lets the system to be used in terminal mode

the solution of using networked homedirectories it's ok for me although it would be good to have it solved

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

the problem with the authentication token could be related to something in the server, if I join a fedora box to server I have the same problems but with a joined centos box all seems ok. I'm going to install the server part in a fedora box and repeat all my testing

thanks

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

most likely it's just that I forgot to tell you to run 'pam-auth-update' after modifying the pam-config file..

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

good news: the workaround of using libpam-cracklib really worked in ubuntu, in fedora the thing also works

the problem was that my testing machines were in a virtualbox with nat networking and in that configuration there can be some problems for making kerberos run correctly:
http://hasustorm.com/books/English/OReilly.Kerberos.The.Definitive.Guide.eBook-LiB.chm/0596004036_kerberos-chp-6-sect-5.html

when switched the network to use bridged mode the things started to work.
I'm going to take a look to the other problems found to think for a clever solution for them

thanks!!!

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

the discovery of dreeipa servers doesn't works because relies in authcobfig through the acutil python package, it's import is comented in dnsclient.py. I have build a patch to make this work using pydns (http://pydns.sourceforge.net/). take a look to it, it wold be nice to include it and/or make freeipa mainstream use it to make the application more portable
I have tested it to install with one server so it's a good idea to test it more

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

ntpdate has not -U option in ubuntu so that makes ntpconf.py crash, this patch removes the -U option and comments some calls to sysconfig files which make the file crash also

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

there is a problem with the insserv package for the i386 architecture which makes that chkconfig can't enable ntp, I have opened the bug 1000834 about this

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "patch to make dns queries for ipa work" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Revision history for this message
Jakub Hrozek (jakub-hrozek) wrote :

Hi,
the FreeIPA upstream already got rid of acutil in favor of python-dns:
http://osdir.com/ml/freeipa-devel/2012-05/msg00076.html

I've created an upstream bug https://fedorahosted.org/freeipa/ticket/2766 on the ntpdate -U issue. Feel free to submit a patch :-)

Revision history for this message
pasqual milvaques (pasqual-milvaques) wrote :

the bug for adding Pam_mkhomedir to the default stack is 557013 (also 566665) although at the end I have used this config file (/usr/share/pam-configs/my_mkhomedir):
Name: activate mkhomedir
Default: yes
Priority: 900
Session-Type: Additional
Session:
        optional pam_mkhomedir.so umask=0077 skel=/etc/skel

both bugs have been stopped for 2 years so perhaps it's a good idea to tweak the freeipa package to do the work of including this in pam

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in freeipa (Ubuntu):
status: New → Confirmed
Revision history for this message
Joshua Dotson (tns9) wrote :

Any news on this?

I get the follow, as of today, running freeipa-client-install --enable-dns-updates --mkhomedir.

root : ERROR LDAP Error: Connect error: A TLS packet with unexpected length was received.

^ on latest FreeIPA on SL 6.3 + latest FreeIPA Client on Ubuntu Server LTS 12.04.2. Both OSes are fully updated.

It's too bad, too, because FreeIPA has done very well on RHEL variants for me.

Thanks,
Joshua

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Please try with current updates, gnutls26 in particular has received updates that might have fixed this in the process, and I can't reproduce this on raring.

Changed in freeipa (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

ipa-client-install works properly on trusty

Changed in freeipa (Ubuntu):
status: Incomplete → Fix Released
Changed in freeipa:
status: New → Confirmed
Revision history for this message
jaseywang (jaseywang) wrote :

After many tries, neither 10.04 nor 12.04 work :-(
So is there any plan to fix them?

Revision history for this message
jaseywang (jaseywang) wrote :

Well, according to this article, I make it work on 12.04, although not perfect:
http://www.redhat.com/archives/freeipa-users/2013-June/msg00091.html

For 10.04, Timo confirmed that there won't any support for that since there is 9 months before reach its EOL, so you have to make it by youself.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.