[Freeipa-users] Easier management of trusted AD users from web UI
I'm exploring using AD trusts, and am trying to find a good way to get better management of trusted objects within FreeIPA. One example, I add an AD user to an external group, and then add that group to a POSIX group. When I want to view all the members of the POSIX group, I can only see the native FreeIPA users. I have to manually go into each nested group, and view all the external members to determine who is in the top group. But from the command line a `getent group FOO` shows nested members fine. Another example, I see an external user in a group, and I want more information about this user. Their name, department, etc. I can't get it. I have to go into AD to find out who this user is. It would be nice if I could see this info from within FreeIPA. Or if I want to add an external user to a group, I have to know that user's exact AD logon name. If I only have their real name, or other information, I can't search for them and then add them to the group. Is there any way to make these types of management tasks simpler? If not, is such a thing on the road map? Or as an alternative, is it possible to use the winsync plugin to pull users from AD, but whenever such a user tries to authenticate, the authentication is performed against AD? So that FreeIPA is used for authorization, but not authentication? Thanks -Patrick -- 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] Error trying to use trusted AD objects: trusted domain object not found
On 2017/5/14 04:19, Alexander Bokovoy wrote: > On su, 14 touko 2017, Patrick Hemmer wrote: >> I'm working on spinning up a FreeIPA server with an AD trust. I've >> followed the official guide >> (https://www.freeipa.org/page/Active_Directory_trust_setup), and >> everything works up to the point of trying to add external members to >> the group. Whenever I try I get: >> >> # ipa group-add-member ad_admins_external --external 'CHEWY\Domain >> Admins' >> [member user]: >> [member group]: >> Group name: ad_admins_external >> Description: ad_domain admins external map >> Failed members: >>member user: >>member group: CHEWY\Domain Admins: trusted domain object not found >> - >> Number of members added 0 >> - >> >> >> I turned up the debugging to 100, re-established the trust, and tried to >> perform the group-add-member again. Logs have uploaded the logs here: >> https://s3.amazonaws.com/phemmer-misc/freeipa-logs.tar.gz >> I'm just testing the procedure on a couple local development VMs, so >> there's nothing sensitive in there. >> >> Confusingly, according to the httpd log the operation was successful: >> [Sun May 14 01:49:24.171867 2017] [:error] [pid 23688] ipa: INFO: >> [jsonserver_session] admin@LOCAL: >> group_add_member/1(u'ad_admins_external', >> ipaexternalmember=(u'CHEWYDomain Admins',), version=u'2.213'): >> SUCCESS >> >> I'm not sure where the issue here lies. So any insight would be >> appreciated. > > The issue is in your choice of IPA domain name: local. This is not going > to work with AD -- as you can see, there are subtle issues. Even though > AD DC accepts a trust to LOCAL forest, it cannot really operate it > internally, thus even looking up forest topology fails at the point when > IPA framework attempts to authenticate. See [1] for list of limitations > in pure Active Directory for single-label domains. > > [1] > https://support.microsoft.com/en-us/help/300684/deployment-and-operation-of-active-directory-domains-that-are-configured-by-using-single-label-dns-names > > We don't recommend using single-label DNS configurations. Even in a lab > environment they are source of various issues. > Thanks, switching to a second level domain did indeed solve the issue. -Patrick -- 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] Error trying to use trusted AD objects: trusted domain object not found
I'm working on spinning up a FreeIPA server with an AD trust. I've followed the official guide (https://www.freeipa.org/page/Active_Directory_trust_setup), and everything works up to the point of trying to add external members to the group. Whenever I try I get: # ipa group-add-member ad_admins_external --external 'CHEWY\Domain Admins' [member user]: [member group]: Group name: ad_admins_external Description: ad_domain admins external map Failed members: member user: member group: CHEWY\Domain Admins: trusted domain object not found - Number of members added 0 - I turned up the debugging to 100, re-established the trust, and tried to perform the group-add-member again. Logs have uploaded the logs here: https://s3.amazonaws.com/phemmer-misc/freeipa-logs.tar.gz I'm just testing the procedure on a couple local development VMs, so there's nothing sensitive in there. Confusingly, according to the httpd log the operation was successful: [Sun May 14 01:49:24.171867 2017] [:error] [pid 23688] ipa: INFO: [jsonserver_session] admin@LOCAL: group_add_member/1(u'ad_admins_external', ipaexternalmember=(u'CHEWYDomain Admins',), version=u'2.213'): SUCCESS I'm not sure where the issue here lies. So any insight would be appreciated. This is with: CentOS/7 7.3.1611 FreeIPA 4.4.0 AD is Windows Server 2008 R2 -Patrick -- 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] Password history based on age, not count?
Would it be reasonable to request a feature for FreeIPA to enforce password history reuse based on age, instead of a count? Meaning configure FreeIPA to enforce that a password cannot be reused within the last 1 year? Then we could remove the minimum time between password changes, and not worry about people cycling through X passwords to be able to reuse one. When we were using OpenLDAP for user account management, I wrote an extension for it to do just that and it was rather convenient (not having to deal with an annoying min-change-time). The whole min-time-between-changes, and number-of-passwords-in-history thing has always seemed like a hack to accomplish the true goal of preventing users from reusing passwords within a certain amount of time. -Patrick -- 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] /var/kerberos/krb5kdc/principal missing
This is what the non-functional version looked like:
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = CLOUD.COM
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
CLIFF.CLOUDBURRITO.COM = {
kdc = i-31f62969.ipa-server.us-west-1.cliff.cloudburrito.com:88
master_kdc = i-31f62969.ipa-server.us-west-1.cliff.cloudburrito.com:88
admin_server = i-31f62969.ipa-server.us-west-1.cliff.cloudburrito.com:749
default_domain = cliff.cloudburrito.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
CLOUD.COM = {
kdc = i-6775b715.ipa-server.us-east-1.cloud.com
kdc = i-32e87151.ipa-server.us-east-1.cloud.com
admin_server = i-31f62969.ipa-server.us-west-1.cliff.cloudburrito.com:749
}
[domain_realm]
.cliff.cloudburrito.com = CLIFF.CLOUDBURRITO.COM
cliff.cloudburrito.com = CLIFF.CLOUDBURRITO.COM
cloud.com = CLOUD.COM
.cloud.com = CLOUD.COM
[dbmodules]
CLIFF.CLOUDBURRITO.COM = {
db_library = ipadb.so
}
This is what I did to fix it:
--- /etc/krb5.conf.orig2014-04-08 12:33:01.376525373 -0400
+++ /etc/krb5.conf2014-04-08 12:33:33.214975855 -0400
@@ -6,7 +6,7 @@
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
- default_realm = CLOUD.COM
+ default_realm = CLIFF.CLOUDBURRITO.COM
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
@@ -22,18 +22,10 @@
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
- CLOUD.COM = {
- kdc = i-6775b715.ipa-server.us-east-1.cloud.com
- kdc = i-32e87151.ipa-server.us-east-1.cloud.com
- admin_server = i-31f62969.ipa-server.us-west-1.cliff.cloudburrito.com:749
- }
-
[domain_realm]
.cliff.cloudburrito.com = CLIFF.CLOUDBURRITO.COM
cliff.cloudburrito.com = CLIFF.CLOUDBURRITO.COM
- cloud.com = CLOUD.COM
- .cloud.com = CLOUD.COM
[dbmodules]
CLIFF.CLOUDBURRITO.COM = {
db_library = ipadb.so
-Patrick
*From: *Rob Crittenden
*Sent: * 2014-04-08 13:33:53 E
*To: *Patrick Hemmer , freeipa-users@redhat.com
*Subject: *Re: [Freeipa-users] /var/kerberos/krb5kdc/principal missing
> Patrick Hemmer wrote:
>> Figured it out.
>> Somehow during the upgrade process, the default_realm changed to one of
>> our other domains we use. I'm guessing some RPM postinstall script
>> pulled the domain out of sssd.conf as that's the only place on the box
>> where that domain is mentioned. We don't touch krb5.conf with any sort
>> of configuration management utility.
>>
>> Anyway, after removing the domain from the krb5.conf and restoring the
>> original settings, ipa started up normally.
>
> That's really strange.. I wonder if authconfig is doing something.
> What exactly did the file look like? We do try to update it to fix the
> dbmodules line but we already know the realm and domain from
> /etc/ipa/default.conf.
>
> rob
>
>>
>> -Patrick
>>
>>
>>
>> *From: *Patrick Hemmer
>> *Sent: * 2014-04-08 11:52:34 E
>> *To: *freeipa-users@redhat.com
>> *Subject: *[Freeipa-users] /var/kerberos/krb5kdc/principal missing
>>
>>> I'm having the exact same issue as
>>> http://www.redhat.com/archives/freeipa-users/2013-October/msg9.html
>>> I upgraded from RHEL-6.3 to RHEL-6.5, and now FreeIPA won't start due
>>> to kadmind not starting.
>>>
>>> The kadmind.log contains an extremely unhelpful:
>>> Apr 08 11:31:20 i-31f62969 kadmind[20850](Error): No such file or
>>> directory while initializing, aborting
>>>
>>> Stracing `/usr/sbin/kadmind -P /var/run/kadmind.pid` results in:
>>> open("/var/kerberos/krb5kdc/principal", O_RDONLY) = -1 ENOENT (No such
>>> file or directory)
>>> gettimeofday({1396971844, 51536}, NULL) = 0
>>> open("/etc/localtime", O_RDONLY)= 4
>>> fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
>>> fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
>>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
>>> 0) = 0x7f25440dd000
>>> read(4,
>>> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"...,
>>> 4096) = 3519
>>> lseek(4, -2252, SEEK_CUR) = 1267
>>> read(4,
>>> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"...,
>>> 4096) = 2252
>>> close(4)= 0
>>> munmap(0x7f25440dd000, 4096)= 0
>>> write(3, "Apr 08 11:44:04 i
Re: [Freeipa-users] /var/kerberos/krb5kdc/principal missing
Figured it out.
Somehow during the upgrade process, the default_realm changed to one of
our other domains we use. I'm guessing some RPM postinstall script
pulled the domain out of sssd.conf as that's the only place on the box
where that domain is mentioned. We don't touch krb5.conf with any sort
of configuration management utility.
Anyway, after removing the domain from the krb5.conf and restoring the
original settings, ipa started up normally.
-Patrick
----
*From: *Patrick Hemmer
*Sent: * 2014-04-08 11:52:34 E
*To: *freeipa-users@redhat.com
*Subject: *[Freeipa-users] /var/kerberos/krb5kdc/principal missing
> I'm having the exact same issue as
> http://www.redhat.com/archives/freeipa-users/2013-October/msg9.html
> I upgraded from RHEL-6.3 to RHEL-6.5, and now FreeIPA won't start due
> to kadmind not starting.
>
> The kadmind.log contains an extremely unhelpful:
> Apr 08 11:31:20 i-31f62969 kadmind[20850](Error): No such file or
> directory while initializing, aborting
>
> Stracing `/usr/sbin/kadmind -P /var/run/kadmind.pid` results in:
> open("/var/kerberos/krb5kdc/principal", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> gettimeofday({1396971844, 51536}, NULL) = 0
> open("/etc/localtime", O_RDONLY)= 4
> fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f25440dd000
> read(4,
> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"...,
> 4096) = 3519
> lseek(4, -2252, SEEK_CUR) = 1267
> read(4,
> "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"...,
> 4096) = 2252
> close(4)= 0
> munmap(0x7f25440dd000, 4096)= 0
> write(3, "Apr 08 11:44:04 i-31f62969 kadmi"..., 105) = 105
> write(2, "kadmind: No such file or directo"..., 64kadmind: No such
> file or directory while initializing, aborting) = 64
> close(3)= 0
> munmap(0x7f25440df000, 4096)= 0
> exit_group(1) = ?
>
> As requested in the linked thread, the dbmodules section looks like this:
> [dbmodules]
> CLIFF.CLOUDBURRITO.COM = {
> db_library = ipadb.so
> }
>
> Another important item of note, I have another IPA server which has
> not been upgraded from 6.3 yet, and the file is missing there too, but
> kadmind is currently running just fine...
>
> Ideas?
>
> -Patrick
>
>
> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] /var/kerberos/krb5kdc/principal missing
I'm having the exact same issue as
http://www.redhat.com/archives/freeipa-users/2013-October/msg9.html
I upgraded from RHEL-6.3 to RHEL-6.5, and now FreeIPA won't start due to
kadmind not starting.
The kadmind.log contains an extremely unhelpful:
Apr 08 11:31:20 i-31f62969 kadmind[20850](Error): No such file or
directory while initializing, aborting
Stracing `/usr/sbin/kadmind -P /var/run/kadmind.pid` results in:
open("/var/kerberos/krb5kdc/principal", O_RDONLY) = -1 ENOENT (No such
file or directory)
gettimeofday({1396971844, 51536}, NULL) = 0
open("/etc/localtime", O_RDONLY)= 4
fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f25440dd000
read(4,
"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., 4096)
= 3519
lseek(4, -2252, SEEK_CUR) = 1267
read(4,
"TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096)
= 2252
close(4)= 0
munmap(0x7f25440dd000, 4096)= 0
write(3, "Apr 08 11:44:04 i-31f62969 kadmi"..., 105) = 105
write(2, "kadmind: No such file or directo"..., 64kadmind: No such file
or directory while initializing, aborting) = 64
close(3)= 0
munmap(0x7f25440df000, 4096)= 0
exit_group(1) = ?
As requested in the linked thread, the dbmodules section looks like this:
[dbmodules]
CLIFF.CLOUDBURRITO.COM = {
db_library = ipadb.so
}
Another important item of note, I have another IPA server which has not
been upgraded from 6.3 yet, and the file is missing there too, but
kadmind is currently running just fine...
Ideas?
-Patrick
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] error setting up replication client
I'm not sure what happened here. The log dir for pki-ca was completely empty. I restarted pki-ca, the log files were created, and it appeared to operate normally. I rebuilt the box from scratch (just to have a clean start) and everything came up perfectly fine. -Patrick On 2013/20/03 12:54, Ade Lee wrote: > Patrick, > > Can you provide some log files? Looks like pkisilent is trying to get > to the first configuration panel on the CA and is getting a 302. > > I would need to see the logs under /var/log/pki-ca for the replica > subsystem. > > Thanks, > Ade Lee > > On Wed, 2013-03-20 at 12:04 -0400, Patrick Hemmer wrote: >> I'm trying to set up an ipa replica, and each time I try the install >> process fails at the same point. When I look in the >> ipareplica-install.log I see a 302 redirection which seems to be >> causing the issue. Any ideas why this is happening (or if something >> else is the issue)? >> >> Thanks >> >> -Patrick >> >> (http://fpaste.org/gbYz/) >> 2013-03-15T17:19:50Z DEBUG stderr= >> 2013-03-15T17:19:50Z DEBUG duration: 5 seconds >> 2013-03-15T17:19:50Z DEBUG [3/17]: configuring certificate server instance >> 2013-03-15T17:19:51Z DEBUG args=/usr/bin/perl /usr/bin/pkisilent ConfigureCA >> -cs_hostname i-d1579ba3.ipa-server.us-east-1.cloud.com -cs_port 9445 >> -client_certdb_dir /tmp/tmp-2l64F1 -client_certdb_pw >> d -preop_pin IWk44JzZT6A78Pha3SrM -domain_name IPA -admin_user >> admin -admin_email root@localhost -admin_password -agent_name >> ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa - >> agent_cert_subject CN=ipa-ca-agent,O=CLOUD.COM -ldap_host >> i-d1579ba3.ipa-server.us-east-1.cloud.com -ldap_port 7389 -bind_dn >> cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ip >> aca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true >> -backup_pwd -subsystem_name pki-cad -token_name internal >> -ca_subsystem_cert_subject_name CN=CA Subsystem,O=CLOUD >> .COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=CLOUD.COM >> -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=CLOUD.COM >> -ca_server_cert_subject_name CN=i-d1579ba3.ipa-server.us-east-1.cloud.com,O= >> CLOUD.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=CLOUD.COM >> -ca_sign_cert_subject_name CN=Certificate Authority,O=CLOUD.COM -external >> false -clone true -clone_p12_file ca.p12 -clone_p12_pa >> ssword -sd_hostname i-6775b715.ipa-server.us-east-1.cloud.com >> -sd_admin_port 443 -sd_admin_name admin -sd_admin_password >> -clone_start_tls true -clone_uri https://i-6775b715.ipa-ser >> ver.us-east-1.cloud.com:443 >> 2013-03-15T17:19:51Z DEBUG stdout=libpath=/usr/lib64 >> ### >> CRYPTO INIT WITH CERTDB:/tmp/tmp-2l64F1 >> tokenpwd: >> # >> Attempting to connect to: i-d1579ba3.ipa-server.us-east-1.cloud.com:9445 >> in TestCertApprovalCallback.approve() >> Peer cert details: >> subject: CN=i-d1579ba3.ipa-server.us-east-1.cloud.com,O=CLOUD.COM >> issuer: CN=Certificate Authority,O=CLOUD.COM >> serial: 3 >> item 1 reason=-8172 depth=1 >> cert details: >> subject: CN=Certificate Authority,O=CLOUD.COM >> issuer: CN=Certificate Authority,O=CLOUD.COM >> serial: 1 >> importing certificate. >> Connected. >> Posting Query = >> https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445//ca/admin/console/config/login?pin=IWk44JzZT6A78Pha3SrM&xml=true >> RESPONSE STATUS: HTTP/1.1 200 OK >> RESPONSE HEADER: Server: Apache-Coyote/1.1 >> RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 >> RESPONSE HEADER: Content-Length: 0 >> RESPONSE HEADER: Date: Fri, 15 Mar 2013 17:19:51 GMT >> RESPONSE HEADER: Connection: keep-alive >> xml returned: >> # >> Attempting to connect to: i-d1579ba3.ipa-server.us-east-1.cloud.com:9445 >> Connected. >> Posting Query = >> https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445//ca/admin/console/config/wizard?p=0&op=next&xml=true >> RESPONSE STATUS: HTTP/1.1 302 Moved Temporarily >> RESPONSE HEADER: Server: Apache-Coyote/1.1 >> RESPONSE HEADER: Set-Cookie: JSESSIONID=A8B36AB92F386DB22B193215907C01AC; >> Path=/ca; Secure >> RESPONSE HEADER: Location: >> https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445/ca/admin/console/config/login >> RESPONSE HEADER: Content-Type: text/html;charset=UTF-
[Freeipa-users] error setting up replication client
I'm trying to set up an ipa replica, and each time I try the install process fails at the same point. When I look in the ipareplica-install.log I see a 302 redirection which seems to be causing the issue. Any ideas why this is happening (or if something else is the issue)? Thanks -Patrick (http://fpaste.org/gbYz/) 2013-03-15T17:19:50Z DEBUG stderr= 2013-03-15T17:19:50Z DEBUG duration: 5 seconds 2013-03-15T17:19:50Z DEBUG [3/17]: configuring certificate server instance 2013-03-15T17:19:51Z DEBUG args=/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname i-d1579ba3.ipa-server.us-east-1.cloud.com -cs_port 9445 -client_certdb_dir /tmp/tmp-2l64F1 -client_certdb_pw d -preop_pin IWk44JzZT6A78Pha3SrM -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa - agent_cert_subject CN=ipa-ca-agent,O=CLOUD.COM -ldap_host i-d1579ba3.ipa-server.us-east-1.cloud.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ip aca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=CLOUD .COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=CLOUD.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=CLOUD.COM -ca_server_cert_subject_name CN=i-d1579ba3.ipa-server.us-east-1.cloud.com,O= CLOUD.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=CLOUD.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=CLOUD.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_pa ssword -sd_hostname i-6775b715.ipa-server.us-east-1.cloud.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password -clone_start_tls true -clone_uri https://i-6775b715.ipa-ser ver.us-east-1.cloud.com:443 2013-03-15T17:19:51Z DEBUG stdout=libpath=/usr/lib64 ### CRYPTO INIT WITH CERTDB:/tmp/tmp-2l64F1 tokenpwd: # Attempting to connect to: i-d1579ba3.ipa-server.us-east-1.cloud.com:9445 in TestCertApprovalCallback.approve() Peer cert details: subject: CN=i-d1579ba3.ipa-server.us-east-1.cloud.com,O=CLOUD.COM issuer: CN=Certificate Authority,O=CLOUD.COM serial: 3 item 1 reason=-8172 depth=1 cert details: subject: CN=Certificate Authority,O=CLOUD.COM issuer: CN=Certificate Authority,O=CLOUD.COM serial: 1 importing certificate. Connected. Posting Query = https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445//ca/admin/console/config/login?pin=IWk44JzZT6A78Pha3SrM&xml=true RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 RESPONSE HEADER: Content-Length: 0 RESPONSE HEADER: Date: Fri, 15 Mar 2013 17:19:51 GMT RESPONSE HEADER: Connection: keep-alive xml returned: # Attempting to connect to: i-d1579ba3.ipa-server.us-east-1.cloud.com:9445 Connected. Posting Query = https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445//ca/admin/console/config/wizard?p=0&op=next&xml=true RESPONSE STATUS: HTTP/1.1 302 Moved Temporarily RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Set-Cookie: JSESSIONID=A8B36AB92F386DB22B193215907C01AC; Path=/ca; Secure RESPONSE HEADER: Location: https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445/ca/admin/console/config/login RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 RESPONSE HEADER: Content-Length: 0 RESPONSE HEADER: Date: Fri, 15 Mar 2013 17:19:51 GMT RESPONSE HEADER: Connection: keep-alive ERROR: unable to parse xml ERROR XML = ERROR: Tag=statushas no values Error in LoginPanel(): status value is null ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2013-03-15T17:19:51Z DEBUG stderr=[Fatal Error] :-1:-1: Premature end of file. org.xml.sax.SAXParseException; Premature end of file. at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:239) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) at ParseXML.parse(ParseXML.java:43) at ConfigureCA.getStatus(ConfigureCA.java:205) at ConfigureCA.checkStatus(ConfigureCA.java:221) at ConfigureCA.checkStatus(ConfigureCA.java:216) at ConfigureCA.LoginPanel(ConfigureCA.java:261) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) 2013-03-15T17:19:51Z CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname i-d1579ba3.ipa-server.us-east-1.cloud.com -cs_port 9445 -client_certdb_dir /tmp/
