Re: [Freeipa-users] freeipa unsecured ports & MITM

[Alexander Bokovoy]

On Tue, 29 Mar 2016, Simo Sorce wrote:

On Tue, 2016-03-29 at 08:51 -0600, Master P. wrote:

Hello,

I am using FreeIPA on the cloud and am worried about MITM attacks.  I'm
assuming all network traffic can be easily read and possibly manipulated by
an attacker.

When following
https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html,
some of the listed ports for FreeIPA (80 and 389) are unencrypted ports.


The only thing port 80 does is redirect to 443.

There is also a CA certificate access on port 80 in case LDAP-based
access didn't work.


Port 389 is the only use LDAP port and clients will use the STARTTLS
command to transition to to a TLS encrypted connection or use GSSAPI and
confidentiality to encrypt the traffic.

Also, any LDAP BIND with password will be refused without STARTTLS
command.

--
/ Alexander Bokovoy

--
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] freeipa unsecured ports & MITM

[Master P.]

Thanks for the quick responses, you have both answered everything I was
looking for!

On Tue, Mar 29, 2016 at 9:48 AM, Alexander Bokovoy 
wrote:

> On Tue, 29 Mar 2016, Simo Sorce wrote:
>
>> On Tue, 2016-03-29 at 08:51 -0600, Master P. wrote:
>>
>>> Hello,
>>>
>>> I am using FreeIPA on the cloud and am worried about MITM attacks.  I'm
>>> assuming all network traffic can be easily read and possibly manipulated
>>> by
>>> an attacker.
>>>
>>> When following
>>>
>>> https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html
>>> ,
>>> some of the listed ports for FreeIPA (80 and 389) are unencrypted ports.
>>>
>>
>> The only thing port 80 does is redirect to 443.
>>
> There is also a CA certificate access on port 80 in case LDAP-based
> access didn't work.
>
> Port 389 is the only use LDAP port and clients will use the STARTTLS
>> command to transition to to a TLS encrypted connection or use GSSAPI and
>> confidentiality to encrypt the traffic.
>>
> Also, any LDAP BIND with password will be refused without STARTTLS
> command.
>
> --
> / Alexander Bokovoy
>
-- 
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 4.2: pki-tomcatd in terrible shape

[Timothy Geier]

> On Mar 29, 2016, at 2:00 AM, Thorsten Scherf  wrote:
> 
> On [Mon, 28.03.2016 18:18], Timothy Geier wrote:
>> 
>>> On Mar 28, 2016, at 12:53 PM, Thorsten Scherf  wrote:
>>> 
>>> On [Sat, 26.03.2016 03:26], Timothy Geier wrote:
 To follow up on this issue, we haven’t been able to get any further since
 last month due to the missing caServerCert profile..the configuration
 files /usr/share/pki/ca/profiles/ca/caServerCert.cfg
 and /var/lib/pki/pki-tomcat/ca/profiles/ca/caServerCert.cfg are present
 and are identical.   The pki-ca package
 passes rpm -V as well.   Are there any other troubleshooting steps we can
 take?
>>> 
>>> Can you please check if the profile is available in the LDAP trees:
>>> 
>>> # ldapsearch -LLLx -D "cn=Directory Manager" -W -b 
>>> cn=certprofiles,cn=ca,$suffix
>> 
>> dn: cn=certprofiles,cn=ca,$suffix
>> objectClass: nsContainer
>> objectClass: top
>> cn: certprofiles
>> 
>>> # ldapsearch -LLLx -D "cn=Directory Manager" -W -b 
>>> ou=certificateProfiles,ou=ca,o=ipaca
>> 
>> dn: ou=certificateProfiles,ou=ca,o=ipaca
>> objectClass: top
>> objectClass: organizationalUnit
>> ou: certificateProfiles
>> 
>>> 
>>> If this is the case, please check if the profile is accessable by the
>>> host:
>>> 
>>> # kinit -kt /etc/krb5.keytab; klist; ipa certprofile-show caIPAserviceCert
>>> 
>> 
>> ipa: ERROR: caIPAserviceCert: Certificate Profile not found
>> 
>>> I either suspect that the profiles have not been properly migrated to
>>> the LDAP tree or that some ACIs are missing to allow access to the
>>> profiles.
>>> 
>> 
>> I suspect you’re right..I ran these same commands on a reference system and 
>> there was
>> a lot more output in the ldapsearches and the ipa certprofile-show command 
>> came back with
>> Profile ID: caIPAserviceCert
>> Profile description: Standard profile for network services
>> Store issued certificates: TRUE
> 
> Yes, this is a known issue which has been fixed in the most recent
> FreeIPA releases 4.2.4 and 4.3.1. 
> I would recommend to upgrade your system to one of those releases. If this is 
> not feasible, I can send you instructions how to fix the issue manually.
> 

It’s currently at 4.2.0-15.el7.centos.3..would the update 
4.2.0-15.0.1.el7.centos.6 have the fix backported?  Also, should 
com.netscape.cmscore.profile be changed in 
/var/lib/pki/pki-tomcat/ca/conf/CS.cfg beforehand?

Thanks,

> Cheers,
> Thorsten
> 





"This message and any attachments may contain confidential information. If you
have received this  message in error, any use or distribution is prohibited. 
Please notify us by reply e-mail if you have mistakenly received this message,
and immediately and permanently delete it and any attachments. Thank you."

-- 
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] Request for Feedback - Managing FreeIPA accounts with OpenUnison

[Marc Boorshtein]

FreeIPAers,

We've built an open source integration "provisioning target" that
works with the JSON web service to provision users and roles inside of
FreeIPA/RH IdM.  We also have a prototype of SSO into the IPAWeb
console using constrained delegation (both thanks to the help received
on this list).  We put together a demo of the capability by deploying
FreeIPA to manage RHEL servers running on Azure.  We also integrated
Cockpit and Graylog into the POC as well.

I'd really appreciate feedback on the integration.  Especially on the
use cases and other features you think would add value to the
integration (and of course any place you think we went terribly
wrong!).


Here's a link to the demo:  https://vimeo.com/160002916
The white-paper that details how we deployed everything:
https://www.tremolosecurity.com/wiki/#!azure.md

and of course the source code:

OpenUnison - https://github.com/TremoloSecurity/OpenUnison
FreeIPA Provisioning Target - https://github.com/TremoloSecurity/Unison-FreeIPA
S4U2Self LastMile - https://github.com/TremoloSecurity/Unison-LastMile-Kerberos

Again, any feedback on the integration would be greatly appreciated!

Thanks


Marc Boorshtein
CTO Tremolo Security
marc.boorsht...@tremolosecurity.com
Twitter - @mlbiam / @tremolosecurity

-- 
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 4.2: pki-tomcatd in terrible shape

[Thorsten Scherf]

On [Mon, 28.03.2016 18:18], Timothy Geier wrote:



On Mar 28, 2016, at 12:53 PM, Thorsten Scherf  wrote:

On [Sat, 26.03.2016 03:26], Timothy Geier wrote:

 To follow up on this issue, we haven’t been able to get any further since
 last month due to the missing caServerCert profile..the configuration
 files /usr/share/pki/ca/profiles/ca/caServerCert.cfg
 and /var/lib/pki/pki-tomcat/ca/profiles/ca/caServerCert.cfg are present
 and are identical.   The pki-ca package
 passes rpm -V as well.   Are there any other troubleshooting steps we can
 take?


Can you please check if the profile is available in the LDAP trees:

# ldapsearch -LLLx -D "cn=Directory Manager" -W -b cn=certprofiles,cn=ca,$suffix


dn: cn=certprofiles,cn=ca,$suffix
objectClass: nsContainer
objectClass: top
cn: certprofiles


# ldapsearch -LLLx -D "cn=Directory Manager" -W -b 
ou=certificateProfiles,ou=ca,o=ipaca


dn: ou=certificateProfiles,ou=ca,o=ipaca
objectClass: top
objectClass: organizationalUnit
ou: certificateProfiles



If this is the case, please check if the profile is accessable by the
host:

# kinit -kt /etc/krb5.keytab; klist; ipa certprofile-show caIPAserviceCert



ipa: ERROR: caIPAserviceCert: Certificate Profile not found


I either suspect that the profiles have not been properly migrated to
the LDAP tree or that some ACIs are missing to allow access to the
profiles.



I suspect you’re right..I ran these same commands on a reference system and 
there was
a lot more output in the ldapsearches and the ipa certprofile-show command came 
back with
 Profile ID: caIPAserviceCert
 Profile description: Standard profile for network services
 Store issued certificates: TRUE


Yes, this is a known issue which has been fixed in the most recent
FreeIPA releases 4.2.4 and 4.3.1. 

I would recommend to upgrade your system to one of those releases. If this 
is not feasible, I can send you instructions how to fix the issue manually.


Cheers,
Thorsten

--
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] IPA users central Home Directories

[Shahzad Malik]

Hi


I have recently configured IPA master and replica server. I am trying to 
configure IPA users central home directories which means when a user 
authenticate through IPA on any client, will have same home directory. To 
achieve this goal, I have configured a NFS server, joined and configured nfs 
with IPA.

I have Rhel 7 and CentOS  7 clients. Rhel clients are working as expected, when 
IPA users are authenticated on Rhel clients they can get home directory from 
nfs server. df -h shows any entry of nfs user home directory mounted.

When a client is Centos 7, users are able to authenticated from IPA and can 
login but can't get home directory from NFS server. I can manually mount a dir 
with nfs server which verifies communication is working between centos client 
and nfs.

All neccesary ports are open and centos configurations are pretty much same as 
Rhel clients. I even disabled selinux, but no luck. Has anyone experienced same 
issue?

Another question: At the moment, there is single nfs serve which is single 
point of failure, what best method I can use for HA of user home directories?

Many Thanks


Regards,


Shez

-- 
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] can migrate-ds be safely re-run if it failed...

[Alexander Bokovoy]

On Tue, 29 Mar 2016, lejeczek wrote:
last - this must most FAQ people wonder - can IPA's 389 backend be 
used in the same/similar fashion samba uses ldap? skipping all the 
kerberos bits? (samba & IPA on the same one box)

For Samba and IPA on the same box, this is configured properly with
ipa-adtrust-install.
when I started I thought to make this samba<=>ipa chatter more 
constructive I should do ... so I wound up with samba(@openldap) 
having/using the same DN as IPA has in 389.
Will it work to do ipa-addtrust-install on that one box with samba+ipa 
?

Can you please re-phrase your question? What "it"? What "would work"?

I've said several times that on IPA master all you need to run is
ipa-adtrust-install and then user 'net conf addshare/delshare/setparm'
to configure specific shares, and use POSIX ACLs in your file system to
define access rules.

See
https://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html
for a demo
--
/ Alexander Bokovoy

--
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] 7.x replica install from 6.x master fails

[Petr Vobornik]

On 03/24/2016 04:29 PM, Ott, Dennis wrote:

I am trying to migrate from OS 6.x / IPA 3.0 to OS 7.x / IPA 4.x. After working
through and solving a few issues, my current efforts fail when setting up the
replica CA.

If I set up a new, pristine master on OS 6.7, I am able to create an OS 7.x
replica without any problem. However, if I try to create a replica from my two
year old test lab instance (production will be another matter for the future) it
fails. The test lab master was created a couple of years ago on OS 6.3 / IPA 2.x
and has been upgraded to the latest versions in the 6.x chain. It is old enough
to have had all the certificates renewed, but I believe I have worked through
all the issues related to that.

Below is what I believe are the useful portions of the pertinent logs. I’ve not
been able to find anything online that speaks to the errors I am seeing

Thanks for your help.


Hello Dennis,

what are the exact versions of pki-ca and ipa-server on the 6.x master 
and 7.x replica?


What kind of CA installation does the old 6.x master install have? Is 
standard installation with CA or does it also use external CA?


I assume it is not self-sign (very old unsupported type, which could be 
converted in 7.x as CA-less).




/var/log/ipareplica-install.log

2016-03-23T21:55:11Z DEBUG Configuring certificate server (pki-tomcatd).
Estimated time: 3 minutes 30 seconds

2016-03-23T21:55:11Z DEBUG   [1/23]: creating certificate server user

2016-03-23T21:55:11Z DEBUG group pkiuser exists

2016-03-23T21:55:11Z DEBUG user pkiuser exists

2016-03-23T21:55:11Z DEBUG   duration: 0 seconds

2016-03-23T21:55:11Z DEBUG   [2/23]: configuring certificate server instance

2016-03-23T21:55:11Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'

2016-03-23T21:55:11Z DEBUG Saving StateFile to
'/var/lib/ipa/sysrestore/sysrestore.state'

2016-03-23T21:55:11Z DEBUG Contents of pkispawn configuration file 
(/tmp/tmpGQ59ZC):

[CA]

pki_security_domain_name = IPA

pki_enable_proxy = True

pki_restart_configured_instance = False

pki_backup_keys = True

pki_backup_password = 

pki_profiles_in_ldap = True

pki_client_database_dir = /tmp/tmp-g0CKZ3

pki_client_database_password = 

pki_client_database_purge = False

pki_client_pkcs12_password = 

pki_admin_name = admin

pki_admin_uid = admin

pki_admin_email = root@localhost

pki_admin_password = 

pki_admin_nickname = ipa-ca-agent

pki_admin_subject_dn = cn=ipa-ca-agent,O=EXAMPLE.COM

pki_client_admin_cert_p12 = /root/ca-agent.p12

pki_ds_ldap_port = 389

pki_ds_password = 

pki_ds_base_dn = o=ipaca

pki_ds_database = ipaca

pki_subsystem_subject_dn = cn=CA Subsystem,O=EXAMPLE.COM

pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=EXAMPLE.COM

pki_ssl_server_subject_dn = cn=pt-idm-vm01.example.com,O=EXAMPLE.COM

pki_audit_signing_subject_dn = cn=CA Audit,O=EXAMPLE.COM

pki_ca_signing_subject_dn = cn=Certificate Authority,O=EXAMPLE.COM

pki_subsystem_nickname = subsystemCert cert-pki-ca

pki_ocsp_signing_nickname = ocspSigningCert cert-pki-ca

pki_ssl_server_nickname = Server-Cert cert-pki-ca

pki_audit_signing_nickname = auditSigningCert cert-pki-ca

pki_ca_signing_nickname = caSigningCert cert-pki-ca

pki_ca_signing_key_algorithm = SHA256withRSA

pki_security_domain_hostname = ptipa1.example.com

pki_security_domain_https_port = 443

pki_security_domain_user = admin

pki_security_domain_password = 

pki_clone = True

pki_clone_pkcs12_path = /tmp/ca.p12

pki_clone_pkcs12_password = 

pki_clone_replication_security = TLS

pki_clone_replication_master_port = 7389

pki_clone_replication_clone_port = 389

pki_clone_replicate_schema = False

pki_clone_uri = https://ptipa1.example.com:443

2016-03-23T21:55:11Z DEBUG Starting external process

2016-03-23T21:55:11Z DEBUG args='/usr/sbin/pkispawn' '-s' 'CA' '-f' 
'/tmp/tmpGQ59ZC'

2016-03-23T21:56:51Z DEBUG Process finished, return code=1

2016-03-23T21:56:51Z DEBUG stdout=Log file:
/var/log/pki/pki-ca-spawn.20160323175511.log

Loading deployment configuration from /tmp/tmpGQ59ZC.

Installing CA into /var/lib/pki/pki-tomcat.

Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.

Installation failed.

2016-03-23T21:56:51Z DEBUG
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
https://urllib3.readthedocs.org/en/latest/security.html

InsecureRequestWarning)

pkispawn: WARNING  ... unable to validate security domain user/password
through REST interface. Interface not available

pkispawn: ERROR... Exception from Java Configuration Servlet: 500
Server Error: Internal Server Error

pkispawn: ERROR... ParseError: not well-formed (invalid token): line
1, column 0:

Re: [Freeipa-users] can migrate-ds be safely re-run if it failed...

[lejeczek]

On 15/03/16 14:36, Alexander Bokovoy wrote:

On Tue, 15 Mar 2016, lejeczek wrote:

On 15/03/16 13:42, Rob Crittenden wrote:

lejeczek wrote:

On 14/03/16 17:06, Rob Crittenden wrote:

lejeczek wrote:

with...

ipa: ERROR: group LDAP search did not return any 
result (search base:
ou=groups,dc=ccnr,dc=biotechnology, objectclass: 
groupofuniquenames,

groupofnames)

I see users went in but later I realized that current 
samba's ou was

"group" not groups.
Can I just re-run migrations?
Yes. It will skip over anything that already exists in 
IPA.
thanks Rob, may I ask why process by defaults looks up 
only objectclass:

groupofuniquenames, groupofnames?

It is conservative but this is why it can be overridden.


Is there a reason it skips ldap+samba typical posixGroup &
sambaGroupMapping?
We haven't had many (any?) reports of migrating from 
ldap+samba.


Lastly, is there a way to preserve account 
locked/disabled status for

posix/samba?
I don't know how it is stored but as long as the schema 
is available in
IPA then the values should be preserved on migration 
unless the

attributes are associated with a blacklisted objectclass.

rob

last - this must most FAQ people wonder - can IPA's 389 
backend be used in the same/similar fashion samba uses 
ldap? skipping all the kerberos bits? (samba & IPA on the 
same one box)
For Samba and IPA on the same box, this is configured 
properly with

ipa-adtrust-install.
when I started I thought to make this samba<=>ipa chatter 
more constructive I should do ... so I wound up with 
samba(@openldap) having/using the same DN as IPA has in 389.
Will it work to do ipa-addtrust-install on that one box with 
samba+ipa ?

many thanks
L.


It uses ipasam PASSDB module instead of ldapsam. This 
module knows IPA
LDAP schema and is capable to do more than ldapsam, but 
effectively you
can use resulting Samba setup in the same way as you do 
with ldapsam.


The configuration is:

1. Install ipa-server-trust-ad (freeipa-server-trust-ad on 
Fedora)

2. Run ipa-adtrust-install to configure both IPA and Samba.
3. Use 'net conf' tool to manage shares.
4. Use POSIX ACLs to set up access rights on the file 
system. See
https://www.redhat.com/archives/freeipa-users/2013-April/msg00270.html 


for inspiration.



--
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] Unable to join FreeIPA client to server

[Adam Bishop]

Client is running ipa-client-3.0.0-47.el6.centos.1.x86_64 on CentOS 6
Servers are running ipa-server-4.2.0-15.0.1.el7.centos.6.x86_64 on CentOS 7

When I try to join the CentOS 6 client to the CentOS 7 servers, 
ipa-client-install is unable to access /ipa/xml, throwing the following error:

  ...
  Connecting: [2001:630:1:177::98]:0
  Failed to set TLS range to tls1.0, tls1.2
  Could not connect socket to [2001:630:1:177::98]:443, error: 
(SSL_ERROR_INVALID_VERSION_RANGE) SSL version range is not valid.
  ...

The full log follows, but I don't see anything interesting or unusual, other 
than HTTPS connections are established OK earlier in the installation process.

I could use a bit of help resolving this - full client debug follows. Both 
systems are running nss 3.19.1 which *should* support TLS1.2., so I'm unsure 
where to start fixing this.

Thanks,

Adam Bishop

  gpg: 0x6609D460

jisc.ac.uk

---

Starting IPA discovery with domain=example.org, servers=None, 
hostname=rms1.example.org
Search for LDAP SRV record in example.org
Search DNS for SRV record of _ldap._tcp.example.org.
DNS record found: 
DNSResult::name:_ldap._tcp.example.org.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:atl-ipa-001.example.org.}
DNS record found: 
DNSResult::name:_ldap._tcp.example.org.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:swi-ipa-001.example.org.}
[Kerberos realm search]
Search DNS for TXT record of _kerberos.example.org.
DNS record found: 
DNSResult::name:_kerberos.example.org.,type:16,class:1,rdata={data:example.org}
Search DNS for SRV record of _kerberos._udp.example.org.
DNS record found: 
DNSResult::name:_kerberos._udp.example.org.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:swi-ipa-001.example.org.}
DNS record found: 
DNSResult::name:_kerberos._udp.example.org.,type:33,class:1,rdata={priority:0,port:88,weight:100,server:atl-ipa-001.example.org.}
[LDAP server check]
Verifying that atl-ipa-001.example.org (realm example.org) is an IPA server
Init LDAP connection with: ldap://atl-ipa-001.example.org:389
Search LDAP server for IPA base DN
Check if naming context 'dc=example,dc=org' is for IPA
Naming context 'dc=example,dc=org' is a valid IPA context
Search for (objectClass=krbRealmContainer) in dc=example,dc=org (sub)
Found: cn=example.org,cn=kerberos,dc=example,dc=org
Discovery result: Success; server=atl-ipa-001.example.org, domain=example.org, 
kdc=swi-ipa-001.example.org,atl-ipa-001.example.org, basedn=dc=example,dc=org
Validated servers: atl-ipa-001.example.org
will use discovered domain: example.org
Start searching for LDAP SRV record in "example.org" (Validating DNS Discovery) 
and its sub-domains
Search DNS for SRV record of _ldap._tcp.example.org.
DNS record found: 
DNSResult::name:_ldap._tcp.example.org.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:swi-ipa-001.example.org.}
DNS record found: 
DNSResult::name:_ldap._tcp.example.org.,type:33,class:1,rdata={priority:0,port:389,weight:100,server:atl-ipa-001.example.org.}
DNS validated, enabling discovery
will use discovered server: atl-ipa-001.example.org
Discovery was successful!
will use discovered realm: example.org
will use discovered basedn: dc=example,dc=org
Hostname: rms1.example.org
Hostname source: Machine's FQDN
Realm: example.org
Realm source: Discovered from LDAP DNS records in atl-ipa-001.example.org
DNS Domain: example.org
DNS Domain source: Discovered LDAP SRV records from example.org
IPA Server: atl-ipa-001.example.org
IPA Server source: Discovered from LDAP DNS records in atl-ipa-001.example.org
BaseDN: dc=example,dc=org
BaseDN source: From IPA server ldap://atl-ipa-001.example.org:389

Continue to configure the system with these values? [no]: yes
args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r example.org
stdout=
stderr=realm not found

User authorized to enroll computers: admin
will use principal provided as option: admin
Synchronizing time with KDC...
Search DNS for SRV record of _ntp._udp.example.org.
No DNS record found
args=/usr/sbin/ntpdate -U ntp -s -b -v atl-ipa-001.example.org
stdout=
stderr=
args=/usr/sbin/ntpdate -U ntp -s -b -v atl-ipa-001.example.org
stdout=
stderr=
args=/usr/sbin/ntpdate -U ntp -s -b -v atl-ipa-001.example.org
stdout=
stderr=
Unable to sync time with IPA NTP server, assuming the time is in sync. Please 
check that 123 UDP port is opened.
Writing Kerberos configuration to /tmp/tmpX2eUdM:
#File modified by ipa-client-install

includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = example.org
  dns_lookup_realm = false
  dns_lookup_kdc = false
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes
  udp_preference_limit = 0


[realms]
  example.org = {
kdc = atl-ipa-001.example.org:88
master_kdc = atl-ipa-001.example.org:88
admin_server = atl-ipa-001.example.org:749
default_domain = example.org
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }


[domain_realm]
  .example.org = example.org
  example.org = 

[Freeipa-users] freeipa unsecured ports & MITM

[Master P.]

Hello,

I am using FreeIPA on the cloud and am worried about MITM attacks.  I'm
assuming all network traffic can be easily read and possibly manipulated by
an attacker.

When following
https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html,
some of the listed ports for FreeIPA (80 and 389) are unencrypted ports.

Should this be a concern or does FreeIPA only use those ports to send
non-sensitive information.  If I disable just the unencrypted ports on my
clients will everything still work?

I don't understand Kerberos much so the same question applies to its ports
as well (88 and 464).

I am also using FreeIPA for DNS but it looks like DNSSEC is not enabled by
default, does this mean an attacker hijacking the DNS connections can get
into my system?

Thanks,

Alex
-- 
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] Unable to join FreeIPA client to server

[Adam Bishop]

On 29 Mar 2016, at 14:29, Adam Bishop  wrote:
> I could use a bit of help resolving this - full client debug follows. Both 
> systems are running nss 3.19.1 which *should* support TLS1.2., so I'm unsure 
> where to start fixing this.

Turns out to be a little easier to solve than I thought; the CentOS 6 client 
was running an older version of NSS than I thought it was.

ipa-client-3.0.0-47.el6.centos.1.x86_64 defaults to requiring tls1.2 , but does 
not depend on a version of NSS that actually supports tls1.2.

Manually installing an updated version of NSS has resolved the problem. 

Regards,

Adam Bishop

 gpg: 0x6609D460

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by 
guarantee which is registered in England under Company No. 5747339, VAT No. GB 
197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, 
BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited 
by guarantee which is registered in England under company number 2881024, VAT 
number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, 
Bristol BS2 0JA. T 0203 697 5800.  


-- 
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