Re: [Freeipa-users] SSS for sudoers confusion
On Tue, 11 Mar 2014, David Taylor wrote: @Dmitri - Thank you for your reply, that is actually one of the documents I read, however there seem to be some steps missing as with the configuration elements in place sudo doesn't work dtaylor is not allowed to run sudo on ipa-client. This incident will be reported. There is some note about configuring a password on the ldap user however following the suggestions I found didn't actually work. From your original email I can see that you put sudo provider configuration into wrong section in sssd.conf. No wonder it does not work. Any provider configuration must be in the domain section. In RHEL 6.5 and before you can do like I describe here: https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html In Fedora 20 you don't need to add anything for IPA case because sssd will set everything up by default for IPA provider. Did you actually read man page sssd-sudo(5)? It has exact configuration changes you need to do. Best regards David Taylor -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Tuesday, 11 March 2014 10:49 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] SSS for sudoers confusion On 03/10/2014 07:34 PM, David Taylor wrote: Hi all, I'm in the process of testing IPA server for centralised authentication of our linux hosts. We run CentOS 6.5 and it's all new so we have no legacy issues. In the lab I've set up an IPA server with the yum install and used a local bind instance which all seems to be working correctly. Where the issues begin is with the sudoers functionality. After reading the manual and consulting Google sensei I found a number of resources that talk about setting up ldap either natively in the nsswitch.conf file or via sssd, I've tried a number of slightly different configurations on the client side with little effect. So the question is what is the process for configuring an IPA system to handle sudo functionality. Any help is greatly appreciated. http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf --nssswitch.conf-- # # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the db in front of files for entries you want to be # looked up first in the databases # # Example: #passwd:db files nisplus nis #shadow:db files nisplus nis #group: db files nisplus nis passwd: files sss shadow: files sss group: files sss #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc:nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc:files services: files sss sudoers:files sss netgroup: files sss publickey: nisplus automount: files sss aliases:files nisplus -- - --- sssd.conf- --- [domain/test.example.net] cache_credentials = True krb5_store_password_if_offline = True krb5_realm = TEST.EXAMPLE.NET krb5_server = ipa-server-1.test.example.net ipa_domain = test.example.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipa-server-1.test.example.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, ipa-server-1.test.example.net ldap_tls_cacert = /etc/ipa/ca.crt ldap_uri = ldap://ipa-server-1.test.example.net [sssd] services = nss, pam, ssh, sudo config_file_version = 2 sudo_provider = ldap ldap_sudo_search_base = ou=sudoers,dc=test,dc=example,dc=net ldap_sasl_mech = GSSAPI ldap_sasl_authid =
Re: [Freeipa-users] install IPA replica multi-hosts (ipa packages version 3.3.3-18)
On 10.3.2014 19:55, Dmitri Pal wrote: On 03/10/2014 11:16 AM, artj...@free.fr wrote: Selon Petr Spacekpspa...@redhat.com: On 7.3.2014 16:57, Dmitri Pal wrote: On 03/07/2014 10:29 AM, artj...@free.fr wrote: Selon Petr Spacekpspa...@redhat.com: On 7.3.2014 14:16,artj...@free.fr wrote: I want to install ipa server with a replica. The replica has 2 NICs : the ipa server is connected on the first interface and all the clients are connected on the second interface. The two networks are completely separated, 2 subnets and not routed. I'm curious - what is the reasoning behind this?:-) The goal is to separate the administration flux and the userland flux. The problem is that it is not that clean. One server can connect to another on different ports and using different protocols for different purposes. And client can actually be a proxy that does some admin tasks via LDAP or executes remote administrative commands. I think may be it is better to explore FW rules. For example create a FW rule that would allow only Kerberos and LDAP connections from a set of hosts that would be clients. Hm but that again would prevent you from enrolling new systems since the ipa-client-install connects to IPA via admin interface during the enrollment stage. May be there is some magic that can be done using DNS zones but I am not sure... Let me summarize this thread to: Sorry, this is not supported. Thanks for your answer; It's clear for me now, I understand why my different tests didn't work. Just for my information because it's a little bit confusing when I read in the FreeIPA_Guide (Fedora18) the following sentence: 19.5. Setting DNS Entries for Multi-Homed Servers Some server machines may support multiple network interface cards (NICs). Multi-homed machines typically have multiple IPs, all assigned to the same hostname. This works fine in FreeIPA most of the time because it listens on all available interfaces, except localhost. For a server to be available through any NIC, edit the DNS zone file and add entries for each IP address. For example: ipaserver IN A 192.168.1.100 ipaserver IN A 192.168.1.101 ipaserver IN A 192.168.1.102 What is the architecture of the Multi-Homed Servers in this case ? What do you mean architecture in this context? The main difference between your setup and the example in docs is that you tried to use two different names for one server but the documentation shows an example where one name is associated with multiple IP addresses. Multiple IP addresses for one name are supported as it is very basic requirement for IPv4 IPv6 dual-stack configuration support. Problems arise when you have multiple names for the same server. Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] install with external CA failed
On 03/10/2014 09:07 PM, Simo Sorce wrote: On Mon, 2014-03-10 at 15:45 -0400, Robert Story wrote: On Mon, 10 Mar 2014 15:44:01 +0100 Jan wrote: JC On 6.3.2014 05:42, Robert Story wrote: JC I'm trying to install on CentOS 6.5 (ipa-server-3.0.0-37.el6.x86_64) JC and an external CA. I'm getting this error: JC [snip] JC Can you please run certutil -V on the issuer certificate JC (CN=Certificate Authority,O=xxx)? That might give us a clue why it is JC invalid. Unfortunately I've already scrapped that install and just went with the internal self-signed CA. So far, the only annoyance is that the webserver also presents a self-signed cert for the UI. Is it safe to replace just the web cert with a cert signed by my local CA? Or might that break something? Import the CA cert in your browser. Simo. Yup, in FreeIPA 4.0 even that step should not be needed given the system shared CA trust storage: https://fedorahosted.org/freeipa/ticket/3504 As for now, you can add the CA certificate also via convenience wizards in IPA UI too: http://vm-236.idm.lab.eng.brq.redhat.com/ipa/config/unauthorized.html Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Red Hat 5 client enrolment fails to Red Hat 6 Server
When I want to enroll en new machine the ipa-client-install process bails
out with the error Failed to retrieve encryption type DES cbc mode with
CRC-32 (#1) .
The output below is the debug output:
[root@apa01-tst ~]# ipa-client-install -d --domain=example.com --mkhomedir
-w otpass --realm=EXAMPLE.COM --ntp-server=ns01.example.com --unattended
root: DEBUG/usr/sbin/ipa-client-install was invoked with
options: {'conf_ntp': True, 'domain': 'example.com', 'uninstall': False,
'force': False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname':
None, 'permit': False, 'server': None, 'prompt_password': False,
'mkhomedir': True, 'dns_updates': False, 'preserve_sssd': False, 'debug':
True, 'on_master': False, 'ca_cert_file': None, 'realm_name': 'EXAMPLE.COM',
'unattended': True, 'ntp_server': 'ns01.example.com', 'principal': None}
root: DEBUGmissing options might be asked for interactively
later
root: DEBUGLoading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
root: DEBUGLoading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
root: DEBUG[IPA Discovery]
root: DEBUGStarting IPA discovery with domain=example.com,
servers=None, hostname=apa01-tst.chn1.oob.example.com
root: DEBUGSearch for LDAP SRV record in example.com
root: DEBUG[ipadnssearchldap]
root: DEBUG[ipadnssearchkrb]
root: DEBUG[ipacheckldap]
root: DEBUGVerifying that auth01.example.com (realm EXAMPLE.COM)
is an IPA server
root: DEBUGInit ldap with: ldap://auth01.example.com:389
root: DEBUGSearch LDAP server for IPA base DN
root: DEBUGCheck if naming context 'dc=pp,dc=ams' is for IPA
root: DEBUGNaming context 'dc=pp,dc=ams' is a valid IPA context
root: DEBUGSearch for (objectClass=krbRealmContainer) in
dc=pp,dc=ams(sub)
root: DEBUGFound: [('cn=EXAMPLE.COM,cn=kerberos,dc=pp,dc=ams',
{'krbSubTrees': ['dc=pp,dc=ams'], 'cn': ['EXAMPLE.COM'],
'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special',
'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top',
'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'],
'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special',
'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal',
'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special'],
'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})]
root: DEBUGDiscovery result: Success; server=auth01.example.com,
domain=example.com, kdc=auth01.example.com, basedn=dc=pp,dc=ams
root: DEBUGValidated servers: auth01.example.com
root: DEBUGwill use domain: example.com
root: DEBUG[ipadnssearchldap(example.com)]
root: DEBUGDNS validated, enabling discovery
root: DEBUGwill use discovered server: auth01.example.com
Discovery was successful!
root: DEBUGwill use cli_realm: EXAMPLE.COM
root: DEBUGwill use cli_basedn: dc=pp,dc=ams
Hostname: apa01-tst.chn1.oob.example.com
Realm: EXAMPLE.COM
DNS Domain: example.com
IPA Server: auth01.example.com
BaseDN: dc=pp,dc=ams
Synchronizing time with KDC...
root: DEBUGargs=/usr/sbin/ntpdate -U ntp -s -b
auth01.example.com
root: DEBUGstdout=
root: DEBUGstderr=
root: DEBUGWriting Kerberos configuration to /tmp/tmpM19nuR:
#File modified by ipa-client-install
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
EXAMPLE.COM = {
kdc = auth01.example.com:88
master_kdc = auth01.example.com:88
admin_server = auth01.example.com:749
default_domain = example.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
root: INFO OTP case, CA cert preexisted, use it
root: DEBUGargs=/usr/sbin/ipa-join -s auth01.example.com -b
dc=pp,dc=ams -d -w
root: DEBUGstdout=
root: DEBUGstderr=request done: ld 0x172d1d10 msgid 1
request done: ld 0x172d1d10 msgid 2
request done: ld 0x172d1d10 msgid 3
Failed to retrieve encryption type DES cbc mode with CRC-32 (#1)
Keytab successfully retrieved and stored in: /etc/krb5.keytab
Certificate subject base is: O=EXAMPLE.COM
Enrolled in IPA realm EXAMPLE.COM
root: DEBUGargs=/usr/kerberos/bin/kinit -k -t /etc/krb5.keytab
host/apa01-tst.chn1.oob.example@example.com
root: DEBUGstdout=
root: DEBUGstderr=kinit(v5): Password incorrect while getting
initial credentials
Failed to obtain host TGT.
Installation failed. Rolling back changes.
IPA client is not configured on this system.
Regards,
Patrick
___
Freeipa-users mailing
Re: [Freeipa-users] Red Hat 5 client enrolment fails to Red Hat 6 Server
Patrick de Ruiter wrote:
When I want to enroll en new machine the ipa-client-install process
bails out with the error Failed to retrieve encryption type DES cbc
mode with CRC-32 (#1) .
The output below is the debug output:
[root@apa01-tst ~]# ipa-client-install -d --domain=example.com
http://example.com --mkhomedir -w otpass --realm=EXAMPLE.COM
http://EXAMPLE.COM --ntp-server=ns01.example.com
http://ns01.example.com --unattended
root: DEBUG/usr/sbin/ipa-client-install was invoked with
options: {'conf_ntp': True, 'domain': 'example.com
http://example.com', 'uninstall': False, 'force': False, 'sssd': True,
'krb5_offline_passwords': True, 'hostname': None, 'permit': False,
'server': None, 'prompt_password': False, 'mkhomedir': True,
'dns_updates': False, 'preserve_sssd': False, 'debug': True,
'on_master': False, 'ca_cert_file': None, 'realm_name': 'EXAMPLE.COM
http://EXAMPLE.COM', 'unattended': True, 'ntp_server':
'ns01.example.com http://ns01.example.com', 'principal': None}
root: DEBUGmissing options might be asked for interactively
later
root: DEBUGLoading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
root: DEBUGLoading StateFile from
'/var/lib/ipa-client/sysrestore/sysrestore.state'
root: DEBUG[IPA Discovery]
root: DEBUGStarting IPA discovery with domain=example.com
http://example.com, servers=None,
hostname=apa01-tst.chn1.oob.example.com
http://apa01-tst.chn1.oob.example.com
root: DEBUGSearch for LDAP SRV record in example.com
http://example.com
root: DEBUG[ipadnssearchldap]
root: DEBUG[ipadnssearchkrb]
root: DEBUG[ipacheckldap]
root: DEBUGVerifying that auth01.example.com
http://auth01.example.com (realm EXAMPLE.COM http://EXAMPLE.COM) is
an IPA server
root: DEBUGInit ldap with: ldap://auth01.example.com:389
http://auth01.example.com:389
root: DEBUGSearch LDAP server for IPA base DN
root: DEBUGCheck if naming context 'dc=pp,dc=ams' is for IPA
root: DEBUGNaming context 'dc=pp,dc=ams' is a valid IPA context
root: DEBUGSearch for (objectClass=krbRealmContainer) in
dc=pp,dc=ams(sub)
root: DEBUGFound: [('cn=EXAMPLE.COM
http://EXAMPLE.COM,cn=kerberos,dc=pp,dc=ams', {'krbSubTrees':
['dc=pp,dc=ams'], 'cn': ['EXAMPLE.COM http://EXAMPLE.COM'],
'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special',
'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass':
['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope':
['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal',
'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special',
'des3-hmac-sha1:normal', 'des3-hmac-sha1:special',
'arcfour-hmac:normal', 'arcfour-hmac:special'], 'krbMaxTicketLife':
['86400'], 'krbMaxRenewableAge': ['604800']})]
root: DEBUGDiscovery result: Success;
server=auth01.example.com http://auth01.example.com,
domain=example.com http://example.com, kdc=auth01.example.com
http://auth01.example.com, basedn=dc=pp,dc=ams
root: DEBUGValidated servers: auth01.example.com
http://auth01.example.com
root: DEBUGwill use domain: example.com http://example.com
root: DEBUG[ipadnssearchldap(example.com http://example.com)]
root: DEBUGDNS validated, enabling discovery
root: DEBUGwill use discovered server: auth01.example.com
http://auth01.example.com
Discovery was successful!
root: DEBUGwill use cli_realm: EXAMPLE.COM http://EXAMPLE.COM
root: DEBUGwill use cli_basedn: dc=pp,dc=ams
Hostname: apa01-tst.chn1.oob.example.com
http://apa01-tst.chn1.oob.example.com
Realm: EXAMPLE.COM http://EXAMPLE.COM
DNS Domain: example.com http://example.com
IPA Server: auth01.example.com http://auth01.example.com
BaseDN: dc=pp,dc=ams
Synchronizing time with KDC...
root: DEBUGargs=/usr/sbin/ntpdate -U ntp -s -b
auth01.example.com http://auth01.example.com
root: DEBUGstdout=
root: DEBUGstderr=
root: DEBUGWriting Kerberos configuration to /tmp/tmpM19nuR:
#File modified by ipa-client-install
[libdefaults]
default_realm = EXAMPLE.COM http://EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
EXAMPLE.COM http://EXAMPLE.COM = {
kdc = auth01.example.com:88 http://auth01.example.com:88
master_kdc = auth01.example.com:88 http://auth01.example.com:88
admin_server = auth01.example.com:749 http://auth01.example.com:749
default_domain = example.com http://example.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.example.com http://example.com = EXAMPLE.COM http://EXAMPLE.COM
example.com http://example.com = EXAMPLE.COM http://EXAMPLE.COM
root: INFO OTP case, CA cert preexisted, use it
root: DEBUGargs=/usr/sbin/ipa-join -s
Re: [Freeipa-users] Joining realm failed: SASL Bind failed Local error (-2) (SOLVED)
Thanks, after a little digging I found that the reverse DNS records were not configured for the masters. Thank You, Rashard Kelly From: Martin Kosek mko...@redhat.com To: rashard.ke...@sita.aero Cc: freeipa-users@redhat.com Date: 03/10/2014 10:17 AM Subject:Re: [Freeipa-users] Joining realm failed: SASL Bind failed Local error (-2) This service should be needed at all in default installation, did you maybe try to run ipa-client-install with --no-sssd option and do not have nss-pam-ldapd package installed? Martin On 03/10/2014 03:11 PM, rashard.ke...@sita.aero wrote: Thanks for the response Martin. The DNS info is configured the same as it is on other clients. I did run the install in debug mode and failed at... Starting nscd: [ OK ] root: DEBUGstderr= root: DEBUGargs=/sbin/chkconfig nscd on root: DEBUGstdout= root: DEBUGstderr= root: DEBUGargs=/sbin/service nslcd status root: DEBUGstdout= root: DEBUGstderr=nslcd: unrecognized service root: INFO nslcd daemon is not installed, skip configuration what could this mean? Ldap is instslled Thank You, Rashard Kelly This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Red Hat 5 client enrolment fails to Red Hat 6 Server
Hi Rob
Ipa client version is :ipa-client-2.1.3-7.el5
[root@apa01-tst ~]# klist -kte /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
-
2 03/11/14 15:55:02 host/apa01-tst.chn1.oob.pp@pp.ams (AES-256 CTS
mode with 96-bit SHA-1 HMAC)
2 03/11/14 15:55:02 host/apa01-tst.chn1.oob.pp@pp.ams (AES-128 CTS
mode with 96-bit SHA-1 HMAC)
2 03/11/14 15:55:02 host/apa01-tst.chn1.oob.pp@pp.ams (Triple DES
cbc mode with HMAC/sha1)
2 03/11/14 15:55:02 host/apa01-tst.chn1.oob.pp@pp.ams (ArcFour with
HMAC/md5)
this is what shows up in the logfile krb5kdc.log on the KDC
Mar 11 15:55:02 auth01.example.com krb5kdc[16846](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: NEEDED_PREAUTH: host/
apa01-tst.chn1.oob.example@example.com for krbtgt/
example@example.com, Additional pre-authentication required
Mar 11 15:55:02 auth01.example.com krb5kdc[16847](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549702, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example@example.com for
krbtgt/example@example.com
Mar 11 15:55:02 auth01.example.com krb5kdc[16847](info): TGS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549702, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example@example.com for
HTTP/auth01.example@example.com
Mar 11 15:55:02 auth01.example.com krb5kdc[16847](info): TGS_REQ (1 etypes
{18}) 10.63.130.33: ISSUE: authtime 1394549702, etypes {rep=18 tkt=18
ses=18}, host/apa01-tst.chn1.oob.example@example.com for krbtgt/
example@example.com
Mar 11 15:55:02 auth01.example.com krb5kdc[16847](info): TGS_REQ (1 etypes
{18}) 10.63.130.33: ISSUE: authtime 1394549702, etypes {rep=18 tkt=18
ses=18}, host/apa01-tst.chn1.oob.example@example.com for krbtgt/
example@example.com
Mar 11 15:55:02 auth01.example.com krb5kdc[16847](info): TGS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.132.21: ISSUE: authtime 1394549702, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example@example.com for
ldap/auth01.example@example.com
Mar 11 15:55:03 auth01.example.com krb5kdc[16847](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: NEEDED_PREAUTH: host/
apa01-tst.chn1.oob.example@example.com for krbtgt/
example@example.com, Additional pre-authentication required
Mar 11 15:55:03 auth01.example.com krb5kdc[16846](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549703, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example@example.com for
krbtgt/example@example.com
Mar 11 15:55:03 auth01.example.com krb5kdc[16846](info): TGS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549703, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example@example.com for
HTTP/auth01.example@example.com
Mar 11 15:55:03 auth01.example.com krb5kdc[16847](info): TGS_REQ (1 etypes
{18}) 10.63.130.33: ISSUE: authtime 1394549703, etypes {rep=18 tkt=18
ses=18}, host/apa01-tst.chn1.oob.example@example.com for krbtgt/
example@example.com
Mar 11 15:55:03 auth01.example.com krb5kdc[16846](info): TGS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.132.21: ISSUE: authtime 1394549703, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example@example.com for
ldap/auth01.example@example.com
Mar 11 15:55:04 auth01.example.com krb5kdc[16846](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: NEEDED_PREAUTH: host/
apa01-tst.chn1.oob.example@example.com for krbtgt/
example@example.com, Additional pre-authentication required
Mar 11 15:55:04 auth01.example.com krb5kdc[16846](info): AS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549704, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example@example.com for
krbtgt/example@example.com
Mar 11 15:55:04 auth01.example.com krb5kdc[16846](info): TGS_REQ (7 etypes
{18 17 16 23 1 3 2}) 10.63.130.33: ISSUE: authtime 1394549704, etypes
{rep=18 tkt=18 ses=18}, host/apa01-tst.chn1.oob.example@example.com for
ldap/auth01.example@example.com
Cheers,
Patrick
On Tue, Mar 11, 2014 at 2:00 PM, Rob Crittenden rcrit...@redhat.com wrote:
Patrick de Ruiter wrote:
When I want to enroll en new machine the ipa-client-install process
bails out with the error Failed to retrieve encryption type DES cbc
mode with CRC-32 (#1) .
The output below is the debug output:
[root@apa01-tst ~]# ipa-client-install -d --domain=example.com
http://example.com --mkhomedir -w otpass --realm=EXAMPLE.COM
http://EXAMPLE.COM --ntp-server=ns01.example.com
http://ns01.example.com --unattended
root: DEBUG/usr/sbin/ipa-client-install was invoked with
options: {'conf_ntp': True, 'domain': 'example.com
http://example.com', 'uninstall': False, 'force': False, 'sssd': True,
'krb5_offline_passwords': True, 'hostname': None,
Re: [Freeipa-users] Migration mode
On 03/11/2014 03:06 PM, Sumit Bose wrote: On Mon, Mar 10, 2014 at 11:09:48PM +0100, Jitse Klomp wrote: On 10-03-14 22:06, Sumit Bose wrote: Thank you. Maybe there is a change in return codes between MIT Kerberos 1.10 (Centos 6) and 1.11 (F20, RHEL7). Can you try to run KRB5_TRACE=/dev/stdout kinit unmigrated_u...@domain.nl on the different platforms and paste the results? I would expect to see [Preauthentication failed] on Centos6 and [Program lacks support for encryption type] on F10 or RHEL7. bye, Sumit http://pastebin.centos.org/8336/ Top one is CentOS, bottom one Fedora. Output on RHEL7 is the same as on Fedora. Thank you for your patience. I was able to reproduce and fix the issue. Do you want a scratch build for F20 or can you wait for the official packages? bye, Sumit Great! Thanks! Do you know how long it will take for the fix to land in the official packages? - Jitse ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] install with external CA failed
On Mon, 10 Mar 2014 16:07:54 -0400 Simo wrote: SS Unfortunately I've already scrapped that install and just went with SS the internal self-signed CA. So far, the only annoyance is that the SS webserver also presents a self-signed cert for the UI. Is it safe to SS replace just the web cert with a cert signed by my local CA? Or might SS that break something? SS SS Import the CA cert in your browser. This is exactly what I'm trying to avoid. Users already have to install our corporate CA cert, and I'd like to avoid having to install two. I'm hoping that the cert for the UI could be swapped for one signed by our existing CA. Robert -- Senior Software Engineer @ Parsons signature.asc Description: PGP signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] install with external CA failed
On 03/11/2014 12:44 PM, Robert Story wrote: On Mon, 10 Mar 2014 16:07:54 -0400 Simo wrote: SSUnfortunately I've already scrapped that install and just went with SSthe internal self-signed CA. So far, the only annoyance is that the SSwebserver also presents a self-signed cert for the UI. Is it safe to SSreplace just the web cert with a cert signed by my local CA? Or might SSthat break something? SS SS Import the CA cert in your browser. This is exactly what I'm trying to avoid. Users already have to install our corporate CA cert, and I'd like to avoid having to install two. I'm hoping that the cert for the UI could be swapped for one signed by our existing CA. Robert -- Senior Software Engineer @ Parsons ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users There are several options: a) Resolve the issue with CA chaining. It might be due to some data missing in the cert issued by your corporate CA when you tried to chain things. We can drill down into that. b) You can use the feature available in IPA 3.3 to use CA-less install. It will be in CentOS 7. In this case you can install IPA without any CA and just use you corporate CA. The down side is that all cert related operations of IPA will be disabled. c) Import the cert into the browser or the common certs store. I vaguely remember that this change might have been ported to 6.5 but I am not sure from top of my head. Thanks Dmitri -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
