Hide Forgot
Description of problem: I am trying to access the XMLRPC Server of FreeIPA via Rubies XMLRPC::Client. This doesn't work, because the service itself sends out Content-Type: text/plain which is wrong in terms of XMLRPC. Ruby itself has a strict sanity check in its XMLRPC Client, and throws an Exception when the returned Content-Type is not text/xml Version-Release number of selected component (if applicable): 3.0.0-26.el6 How reproducible: use XMLRPC::Client of Ruby 1.9 and some gssapi magic to send out the kerb authentication headers. and use this code: For example you can use this code: require 'xmlrpc/client' require 'base64' require 'gssapi' class FreeIPA attr_accessor :ipaurl attr_accessor :kerb_service def initialize(ipaurl,kerb_service='HTTP') uri=URI.parse ipaurl @ipaurl=ipaurl @kerb_service=kerb_service @ipa=XMLRPC::Client.new2(@ipaurl) @ipa.instance_variable_get(:@http).instance_variable_set(:@verify_mode, OpenSSL::SSL::VERIFY_NONE) @gsscli=GSSAPI::Simple.new(uri.host,@kerb_service) @token= @ipa.http_header_extra={ 'Authorization'=>"Negotiate #{Base64.strict_encode64(@token)}", 'Referer' => @ipaurl, 'Content-Type' => 'text/xml; charset=utf-8', 'Accept' => 'text/plain' } end def user_list user_list=('user_find') user_list end end a=FreeIPA.new('<your ipa server url i.e. http://ipaurl/ipa/xml>','HTTP') puts a.user_list Steps to Reproduce: 1. adjust the ipa url in the script 2. kinit <kerb user which has write to admin IPA> 3. start the script Actual results: ruby kerb.rb /usr/lib/ruby/1.9.1/xmlrpc/client.rb:557:in `do_rpc': Wrong content-type (received 'text/plain' but expected 'text/xml') (RuntimeError) from /usr/lib/ruby/1.9.1/xmlrpc/client.rb:420:in `call2' from /usr/lib/ruby/1.9.1/xmlrpc/client.rb:410:in `call' from kerb.rb:30:in `user_list' from kerb.rb:39:in `<main>' Expected results: ruby kerb.rb {"count"=>3, "truncated"=>false, "result"=>[{"dn"=>"uid=admin,cn=users,cn=accounts,dc=intern,dc=sourcecode,dc=de", "has_keytab"=>true, "uid"=>["admin"], "loginshell"=>["/bin/bash"], "uidnumber"=>["723200000"], "gidnumber"=>["723200000"], "has_password"=>true, "sn"=>["Administrator"], "homedirectory"=>["/home/admin"], "nsaccountlock"=>false}, {"dn"=>"uid=sadig,cn=users,cn=accounts,dc=intern,dc=sourcecode,dc=de", "has_keytab"=>true, "uid"=>["sadig"], "loginshell"=>["/bin/sh"], "uidnumber"=>["723200001"], "gidnumber"=>["723200001"], "has_password"=>true, "sn"=>["Adig"], "homedirectory"=>["/home/sadig"], "mail"=>["sadig.de"], "givenname"=>["Stephan"], "nsaccountlock"=>false}, {"dn"=>"uid=shermann,cn=users,cn=accounts,dc=intern,dc=sourcecode,dc=de", "has_keytab"=>true, "uid"=>["shermann"], "loginshell"=>["/bin/sh"], "uidnumber"=>["723200004"], "gidnumber"=>["723200004"], "has_password"=>true, "sn"=>["Adig"], "homedirectory"=>["/home/shermann"], "mail"=>["shermann.de"], "givenname"=>["Stephan"], "nsaccountlock"=>false}], "summary"=>"3 users matched"} Additional info:
I found out that this issue only reproduces when the client is not using the FreeIPA sessions and is doing the full delegation: # ipa -vv user-show admin ipa: INFO: trying https://vm-133.idm.lab.bos.redhat.com/ipa/xml ... reply: 'HTTP/1.1 200 Success\r\n' ... header: Content-Type: text/plain; charset=UTF-8 ... header: WWW-Authenticate: Negotiate YIGYBgkqhkiG9x...JDIK9jtCPOA4JKDI= ... User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 1059000000 GID: 1059000000 Account disabled: False Password: True Member of groups: admins, trust admins Kerberos keys available: True With second try the session is now used and correct Content-Type shows: # ipa -vv user-show admin ipa: INFO: trying https://vm-133.idm.lab.bos.redhat.com/ipa/session/xml ... reply: 'HTTP/1.1 200 Success\r\n' ... header: Set-Cookie: ipa_session=503afc96694e344c68d27fe680cd001c; Domain=vm-133.idm.lab.bos.redhat.com; Path=/ipa; Expires=Fri, 21 Jun 2013 10:37:56 GMT; Secure; HttpOnly ... header: Content-Type: text/xml; charset=utf-8 ... User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 1059000000 GID: 1059000000 Account disabled: False Password: True Member of groups: admins, trust admins Kerberos keys available: True Your case can be easily reproducible the following way: # ipa --delegate -vv user-show admin ipa: INFO: trying https://vm-133.idm.lab.bos.redhat.com/ipa/xml ... reply: 'HTTP/1.1 200 Success\r\n' ... header: WWW-Authenticate: Negotiate ... header: Content-Type: text/plain; charset=UTF-8 To sum it up, it is indeed a bug and I will clone it to upstream ticket.
Upstream ticket: https://fedorahosted.org/freeipa/ticket/3745
Fixed upstream: master: https://fedorahosted.org/freeipa/changeset/689399fce930fb9d28ca81dfffbad411d12186e3 ipa-3-2: https://fedorahosted.org/freeipa/changeset/10fac29e242d0903a31efdaa05c20894d1f8322a
Verified. IPA version: ============ [root@rhel65-master ~]# rpm -q ipa-server ipa-server-3.0.0-37.el6.x86_64 [root@rhel65-master ~]# [root@rhel65-master ~]# ipa --delegate -vv user-show admin ipa: INFO: trying https://rhel65-master.testrelm.com/ipa/xml ipa: INFO: Forwarding 'user_show' to server u'https://rhel65-master.testrelm.com/ipa/xml' send: u'POST /ipa/xml HTTP/1.0\r\nHost: rhel65-master.testrelm.com\r\nAccept-Language: en-us\r\nReferer: https://rhel65-master.testrelm.com/ipa/xml\r\nAuthorization: negotiate YIIFDgYJKoZIhvcSAQICAQBuggT9MIIE .... reply: 'HTTP/1.1 200 Success\r\n' .... header: Content-Type: text/xml; charset=utf-8 [root@rhel65-master ~]#
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1651.html