Re: [Freeipa-users] Closing off some ports for FreeIPA

2016-04-01 Thread Alexander Bokovoy 

On Fri, 01 Apr 2016, Jeremy Utley wrote:

Hello all on the list.

First off, if this is documented somewhere I'm not aware of, I apologize
for the noise.  I've spent a couple of hours google searching google
without success, so pointers to any documentation I've missed would be
greatly appreciated!

We're in the process of setting up a FreeIPA system within our ultra-secure
PCI zone.  It's currently working well, and we are very happy with it.
However, we know that come our next audit, we're going to get hit on a few
things, so I would like to ask about blocking off some additional ports
(specifically 80, 389, 53).  53 I think will be safe to block off, as all
our clients actually use a dedicated caching DNS system with unbound, which
has been configured to forward all queries for the zone "ipa.domain.com" to
the FreeIPA servers, so we should be able to block 53 from everywhere but
the unbound servers without breakage.

However, port 80 and 389 I'm not so sure about.  I know most things that
hit port 80 get redirected to 443, and 389 provides STARTTLS functionality,
but in theory, these ports can provide unencrypted communications, and
therefore our auditors will ask that they be closed off.  However, in my
research so far, I have not been able to find out what the ramifications
would be to blocking these ports for the IPA system itself (would it fall
back to using SSL on 636? Would API calls fail if port 80 is closed?).

You can always disable anonymous bind for LDAP by raising min ssf above
zero. You can read in more details how to increase security of 389-ds
communications here:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/SecureConnections.html

FreeIPA does not require port 80 to be working for its API calls.

Switching to LDAPS via port 636 is not recommended. The use of LDAP over
SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized
in any formal specification. This usage has been deprecated along with
LDAPv2, which was officially retired in 2003.

--
/ 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] Closing off some ports for FreeIPA

2016-04-01 Thread Jeremy Utley 
On Fri, Apr 1, 2016 at 2:57 PM, Rob Crittenden  wrote:

> Jeremy Utley wrote:
>
>> Hello all on the list.
>>
>> First off, if this is documented somewhere I'm not aware of, I apologize
>> for the noise.  I've spent a couple of hours google searching google
>> without success, so pointers to any documentation I've missed would be
>> greatly appreciated!
>>
>> We're in the process of setting up a FreeIPA system within our
>> ultra-secure PCI zone.  It's currently working well, and we are very
>> happy with it.  However, we know that come our next audit, we're going
>> to get hit on a few things, so I would like to ask about blocking off
>> some additional ports (specifically 80, 389, 53).  53 I think will be
>> safe to block off, as all our clients actually use a dedicated caching
>> DNS system with unbound, which has been configured to forward all
>> queries for the zone "ipa.domain.com " to the
>> FreeIPA servers, so we should be able to block 53 from everywhere but
>> the unbound servers without breakage.
>>
>> However, port 80 and 389 I'm not so sure about.  I know most things that
>> hit port 80 get redirected to 443, and 389 provides STARTTLS
>> functionality, but in theory, these ports can provide unencrypted
>> communications, and therefore our auditors will ask that they be closed
>> off.  However, in my research so far, I have not been able to find out
>> what the ramifications would be to blocking these ports for the IPA
>> system itself (would it fall back to using SSL on 636? Would API calls
>> fail if port 80 is closed?).
>>
>> I also know that the ipa-client-install script will check to ensure
>> these ports are open - temporarily opening them for the client setup
>> will not be an issue, if we can close it back down after that.  We do
>> not add systems within this zone very often, so this is a minor issue.
>>
>> Thanks for any advice you can give!
>>
>> Jeremy
>>
>>
>>
> See this thread from earlier this week,
> https://www.redhat.com/archives/freeipa-users/2016-March/msg00295.html
>
> rob
>

Thank you, Rob!  I think that will answer my questions, and hopefully the
auditors!

Jeremy
-- 
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] Closing off some ports for FreeIPA

2016-04-01 Thread Rob Crittenden 

Jeremy Utley wrote:

Hello all on the list.

First off, if this is documented somewhere I'm not aware of, I apologize
for the noise.  I've spent a couple of hours google searching google
without success, so pointers to any documentation I've missed would be
greatly appreciated!

We're in the process of setting up a FreeIPA system within our
ultra-secure PCI zone.  It's currently working well, and we are very
happy with it.  However, we know that come our next audit, we're going
to get hit on a few things, so I would like to ask about blocking off
some additional ports (specifically 80, 389, 53).  53 I think will be
safe to block off, as all our clients actually use a dedicated caching
DNS system with unbound, which has been configured to forward all
queries for the zone "ipa.domain.com " to the
FreeIPA servers, so we should be able to block 53 from everywhere but
the unbound servers without breakage.

However, port 80 and 389 I'm not so sure about.  I know most things that
hit port 80 get redirected to 443, and 389 provides STARTTLS
functionality, but in theory, these ports can provide unencrypted
communications, and therefore our auditors will ask that they be closed
off.  However, in my research so far, I have not been able to find out
what the ramifications would be to blocking these ports for the IPA
system itself (would it fall back to using SSL on 636? Would API calls
fail if port 80 is closed?).

I also know that the ipa-client-install script will check to ensure
these ports are open - temporarily opening them for the client setup
will not be an issue, if we can close it back down after that.  We do
not add systems within this zone very often, so this is a minor issue.

Thanks for any advice you can give!

Jeremy




See this thread from earlier this week, 
https://www.redhat.com/archives/freeipa-users/2016-March/msg00295.html


rob

--
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] Closing off some ports for FreeIPA

2016-04-01 Thread Jeremy Utley 
Hello all on the list.

First off, if this is documented somewhere I'm not aware of, I apologize
for the noise.  I've spent a couple of hours google searching google
without success, so pointers to any documentation I've missed would be
greatly appreciated!

We're in the process of setting up a FreeIPA system within our ultra-secure
PCI zone.  It's currently working well, and we are very happy with it.
However, we know that come our next audit, we're going to get hit on a few
things, so I would like to ask about blocking off some additional ports
(specifically 80, 389, 53).  53 I think will be safe to block off, as all
our clients actually use a dedicated caching DNS system with unbound, which
has been configured to forward all queries for the zone "ipa.domain.com" to
the FreeIPA servers, so we should be able to block 53 from everywhere but
the unbound servers without breakage.

However, port 80 and 389 I'm not so sure about.  I know most things that
hit port 80 get redirected to 443, and 389 provides STARTTLS functionality,
but in theory, these ports can provide unencrypted communications, and
therefore our auditors will ask that they be closed off.  However, in my
research so far, I have not been able to find out what the ramifications
would be to blocking these ports for the IPA system itself (would it fall
back to using SSL on 636? Would API calls fail if port 80 is closed?).

I also know that the ipa-client-install script will check to ensure these
ports are open - temporarily opening them for the client setup will not be
an issue, if we can close it back down after that.  We do not add systems
within this zone very often, so this is a minor issue.

Thanks for any advice you can give!

Jeremy
-- 
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] start and stop of ipa commands in systemd

2016-04-01 Thread Martin (Lists) 
Hallo

I have a question regarding enabling/disabling separate ipa parts in
systemd. Is it necessarry or required to have httpd, directory server,
named memcache and all the other ipa services to be enabled in systemd?
Or is it recomended to have only the main ipa service enabled (and all
the other disabled)?

Regards
Martin

-- 
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] using sudo in ipa

2016-04-01 Thread Michael ORourke 
Jeffrey,You will want to use the Sudo Option "!authenticate".-Mike-Original Message-
From: "Armstrong, Jeffrey" 
Sent: Apr 1, 2016 1:14 PM
To: "freeipa-users@redhat.com" 
Subject: [Freeipa-users] using sudo in ipa














Hi 
 
I would like to know how to configure sudo in the IdM environment. I need to know how to configure sudo access without asking for a password.
 
 
 
 
Jeffrey Armstrong –Senior ECS Engineer
ECMS – Application Support Team
Office Phone – 770-270-7421
Cell Phone – 404-323-7386

 





-- 
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] using sudo in ipa

2016-04-01 Thread Armstrong, Jeffrey 
Hi

I would like to know how to configure sudo in the IdM environment. I need to 
know how to configure sudo access without asking for a password.




Jeffrey Armstrong -Senior ECS Engineer
ECMS - Application Support Team
Office Phone - 770-270-7421
Cell Phone - 404-323-7386
[For Email_GSOC logo_color]

-- 
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] Install/promote new CA old one corrupted before backups

2016-04-01 Thread McNiel, Craig 
Sadly -

I don't think that CA is installed on other replica's  They were installed
following the replica-prepare and replica-install process with nothing else
done outside of this process to install CA.

I did not have backups yet when the incident occurred so I only have the
replica's created from the original CA/master

The documentation that I was following was the following

http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master

I rapidly ran into issues with this on the replica's which I suspect is due
to them not having CA installed.

Thanks !

Craig

On Fri, Apr 1, 2016 at 2:15 AM, Martin Basti  wrote:

>
>
> On 31.03.2016 16:09, McNiel, Craig wrote:
>
> I was installing a 7 host IPA with ipa01 being the CA and the others being
> replicas of this node.  This was to be the production installation of IPA
> and the admins/users started using it prior to the installation being
> completed and before I had snapshots/backup created of the servers.
>
> The ipa01 host disk was corrupted so I no longer have a CA just the other
> 6 nodes.  How can I install/promote or otherwise recreate the CA?  I have
> looked online for instructions but, I run into issues almost immediately
> with the accuracy for the version I'm using in the documenation as many of
> the files it indicates need updates don't even exist.
>
> Thanks
>
> ipa-python-4.2.0-15.el7.centos.3.x86_64
> ipa-admintools-4.2.0-15.el7.centos.3.x86_64
> ipa-server-dns-4.2.0-15.el7.centos.3.x86_64
> sssd-ipa-1.13.0-40.el7_2.1.x86_64
> ipa-server-4.2.0-15.el7.centos.3.x86_64
> libipa_hbac-1.13.0-40.el7_2.1.x86_64
> ipa-client-4.2.0-15.el7.centos.3.x86_64
>
>
>
>
>
> Hello,
>
> Several things are not clear to me from you email. Can you please answer
> following questions?
>
> Do you have CA installed on other replicas?
> Do you have backup of the original server (ipa-backup, or snapshot)?
> Which documentation did you follow?
> What did you try?
>
> Martin Basti
>



-- 

*Craig McNiel*

Assessment and Instruction

2510 North Dodge Street
Iowa City, Iowa 52240

D: 319-341-6390
C: 319-430-9252
T: 877-627- (Team On-call Support)

Pearson
Always Learning
Learn more at www.pearsonassessments.com
-- 
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 Deployment Proposal (request for recommendations)

2016-04-01 Thread Petr Spacek 
Hello,

most importantly:
- FreeIPA does not support real multi-tenancy
- FreeIPA is not a general purpose DNS server and does not (and will not)
support DNS views

If real multi-tenancy is required or not depends on your use-case and
possibilities your users have.

Do users join their custom machines into FreeIPA? If not and everything is
let's say hidden behind web app, it might be possible to hack it in a way
which pretends multi-tenancy.


Missing support for DNS views can be worked around with custom scripting or
even better: FreeIPA team is looking forward to better integration
capabilities with external DNS infrastructure. If you are willing to work with
us on it the progress will be faster :-)

Petr^2 Spacek

On 1.4.2016 00:22, Michael S. Moody wrote:
> Hello FreeIPA Devs/Mailing List,
> 
> We use FreeIPA to great success in several places, but we want to roll it
> out for us. Thus, we want to ask about best practices for the type of
> deployment we’re planning. First, FreeIPA is truly awesome, and the glue
> that holds all these pieces together is really a phenomenal achievement. We
> want to set up our FreeIPA deployment according to best practices.
> 
> As it stands today, we want to implement FreeIPA to take over the
> authentication duties and DNS duties of an infrastructure which we are in
> the process of rebuilding from scratch, so we’re not worried about
> retroactively making things work on older systems. This is an important
> point for us, basically consider that we’re doing everything from scratch,
> and re-basing off of CentOS 7. (Apologies in advance for the wall-of-text).
> 
> Who we are:
> 
> We are a Managed Services Provider with multiple clients, and manage our
> clients’ systems end-to-end. This enables us to have full control over the
> infrastructure.
> 
> Topology:
> 
> We currently have 3 (where we’ll place FreeIPA at least) datacenter
> facilities in the USA, and are bringing a 4th DC online in the EU shortly.
> These datacenters are protected via enterprise-grade hardware firewalls,
> and we have VPNs across the DCs to allow our various infrastructure pieces
> to communicate on internal subnets vs across the public WAN. Additionally,
> we advertise our own IP addresses via BGP. We also have (bind-based) DNS in
> each DC, but primarily for external purposes.
> 
> Private:
> 
> US-EAST: 172.29.0.0/19
> 
> US-WEST: 172.29.32.0/19
> 
> US-SOUTH: 172.29.64.0/19
> 
> EU-WEST: 172.29.96.0/19
> 
> Public:
> 
> US-EAST: 1.1.1.0/24
> 
> US-WEST: 1.1.2.0/24
> 
> US-SOUTH: 1.1.3.0/24
> 
> EU-WEST: 1.1.4.0/24
> 
> Goals:
> 
>1.
> 
>We want to have centralized authentication for our entire infrastructure.
>2.
> 
>We want the authentication to be highly available (FreeIPA replicas)
>3.
> 
>We want to have a drastically improved DNS system that handles both
>external (domain names) and internal (systems).
>4.
> 
>We want that DNS system to also be highly available (FreeIPA replicas
>with bind-ldap as the backend seems to be the best way)
>5.
> 
>We want to use our own SSL certificates if at all possible (wildcard
>certificates, letsencrypt, etc)
>6.
> 
>We would like to be multi-tenant with domains/realms/whatever so that
>CLIENT1 can have their authentication of their systems centralized through
>our FreeIPA. Similar for CLIENT2, CLIENT3, etc. The clients don’t care, so
>how this is set up is up to us/best practices.
>7.
> 
>As part of the multi-tenancy, we don’t want all users to be able to see
>all users. To be more clear, we want to have 1 FreeIPA infrastructure that
>can use our domain (let’s call it GREATMSP.COM), and have systems for
>CLIENT1 as part of CLIENT1.GREATMSP.COM or whatever the best way is. We
>also want where if they login to FreeIPA, they’ll only see their
>users/systems.
>8.
> 
>If we use GREATMSP.COM as the domain, we of course want to still have
>all of our normal DNS records (MX, NS, etc, etc). We’re perfectly good with
>(and prefer) using the more robust FreeIPA as nameservers for our root
>domain name.
>9.
> 
>We would like users to be able to self manage (FreeIPA web ui)
>10.
> 
>We plan to have at least 2 x FreeIPA servers in each DC, with the more
>likely scenario being 4 x in each DC.
>11.
> 
>We want to use DNSSEC wherever possible. Because security.
>12.
> 
>Ideally, can we use the FreeIPA servers as NTP servers?
> 
> 
> Questions:
> 
>1.
> 
>What services/ports can we safely expose to the outside world, and what
>services/ports NEED to be exposed to the outside world for this to work
>effectively with systems in multiple DCs?
>2.
> 
>As part of the above, should authentication only be done across the VPN?
>3.
> 
>Can we safely use our main domain name (GREATMSP.COM) as the domain for
>FreeIPA? As part of this, we have say, TICKETING.GREATMSP.COM (a web app
>

Re: [Freeipa-users] Install/promote new CA old one corrupted before backups

2016-04-01 Thread Martin Basti 



On 31.03.2016 16:09, McNiel, Craig wrote:
I was installing a 7 host IPA with ipa01 being the CA and the others 
being replicas of this node.  This was to be the production 
installation of IPA and the admins/users started using it prior to the 
installation being completed and before I had snapshots/backup created 
of the servers.


The ipa01 host disk was corrupted so I no longer have a CA just the 
other 6 nodes.  How can I install/promote or otherwise recreate the 
CA?  I have looked online for instructions but, I run into issues 
almost immediately with the accuracy for the version I'm using in the 
documenation as many of the files it indicates need updates don't even 
exist.


Thanks

ipa-python-4.2.0-15.el7.centos.3.x86_64
ipa-admintools-4.2.0-15.el7.centos.3.x86_64
ipa-server-dns-4.2.0-15.el7.centos.3.x86_64
sssd-ipa-1.13.0-40.el7_2.1.x86_64
ipa-server-4.2.0-15.el7.centos.3.x86_64
libipa_hbac-1.13.0-40.el7_2.1.x86_64
ipa-client-4.2.0-15.el7.centos.3.x86_64






Hello,

Several things are not clear to me from you email. Can you please answer 
following questions?


Do you have CA installed on other replicas?
Do you have backup of the original server (ipa-backup, or snapshot)?
Which documentation did you follow?
What did you try?

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