[Freeipa-users] Re: IPA Trust between Samba 4.10 and FreeIPA 4.7

[Dirk Streubel via FreeIPA-users]

Hello Lars, hello Alexander,

yes, you are right Lars. It is about AD users from a Samba-based domain (Fedora 
30 with Samba 4.10)  accessing FreeIPA resources.
I take this instruction from the official IPA Web Side 
(https://www.freeipa.org/page/Active_Directory_trust_setup)
and i get no access as a Windows Domain Admin to freeipa Resources.

With Windows 2012 it works, no problem. :-(

Alexander, do yo have in Mind when the other way would be implemented. I think 
this would be a great feature to access as an FreeIPA User to an Windows / 
Samba AD and use Resource from the AD Side.

Regards 
Dirk


 

 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: cert validation failed

[Petar Kozić via FreeIPA-users]

Here is the log files. I just want to inform you that I have that problem
now also on Ubuntu 14.40 and Debian 8.
On Ubuntu ipa client version is 3.3, maybe problem is there.

In mean time I enrolled several more Ubuntu 18.04 instances without
problem.

On this Debian 8 and Ubuntu 14.40 I just try with options —ca-cert-file
which I copied from master but same error.

Thank you

Petar




2019-05-20T11:13:47Z DEBUG [IPA Discovery]

2019-05-20T11:13:47Z DEBUG Starting IPA discovery with domain=example.com,
servers=['myipaserver.example.com'], hostname=myclient.example.net

2019-05-20T11:13:47Z DEBUG Server and domain forced

2019-05-20T11:13:47Z DEBUG [Kerberos realm search]

2019-05-20T11:13:47Z DEBUG Search DNS for TXT record of _
kerberos.example.com

2019-05-20T11:13:47Z DEBUG DNS record not found: NXDOMAIN

2019-05-20T11:13:47Z DEBUG [LDAP server check]

2019-05-20T11:13:47Z DEBUG Verifying that myipaserver.example.com (realm
None) is an IPA server

2019-05-20T11:13:47Z DEBUG Init LDAP connection to: myipaserver.example.com

2019-05-20T11:13:48Z DEBUG Search LDAP server for IPA base DN

2019-05-20T11:13:49Z DEBUG Check if naming context 'dc=example,dc=com' is
for IPA

2019-05-20T11:13:49Z DEBUG Naming context 'dc=example,dc=com' is a valid
IPA context

2019-05-20T11:13:49Z DEBUG Search for (objectClass=krbRealmContainer) in
dc=example,dc=com (sub)

2019-05-20T11:13:49Z DEBUG Found: cn=example.com
,cn=kerberos,dc=example,dc=com

2019-05-20T11:13:49Z DEBUG Discovery result: Success; server=
myipaserver.example.com, domain=example.com, kdc=None,
basedn=dc=example,dc=com

2019-05-20T11:13:49Z DEBUG Validated servers: myipaserver.example.com

2019-05-20T11:13:49Z DEBUG will use discovered domain: example.com

2019-05-20T11:13:49Z DEBUG Using servers from command line, disabling DNS
discovery

2019-05-20T11:13:49Z DEBUG will use provided server: myipaserver.example.com

2019-05-20T11:13:49Z DEBUG will use discovered realm: example.com

2019-05-20T11:13:49Z DEBUG will use discovered basedn: dc=example,dc=com

2019-05-20T11:13:49Z INFO Hostname: myclient.example.net

2019-05-20T11:13:49Z DEBUG Hostname source: Provided as option

2019-05-20T11:13:49Z INFO Realm: example.com

2019-05-20T11:13:49Z DEBUG Realm source: Discovered from LDAP DNS records
in myipaserver.example.com

2019-05-20T11:13:49Z INFO DNS Domain: example.com

2019-05-20T11:13:49Z DEBUG DNS Domain source: Forced

2019-05-20T11:13:49Z INFO IPA Server: myipaserver.example.com

2019-05-20T11:13:49Z DEBUG IPA Server source: Provided as option

2019-05-20T11:13:49Z INFO BaseDN: dc=example,dc=com

2019-05-20T11:13:49Z DEBUG BaseDN source: From IPA server ldap://
myipaserver.example.com:389

2019-05-20T11:13:49Z DEBUG Starting external process

2019-05-20T11:13:49Z DEBUG args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab
-r example.com

2019-05-20T11:13:49Z DEBUG Process finished, return code=5

2019-05-20T11:13:49Z DEBUG stdout=

2019-05-20T11:13:49Z DEBUG stderr=realm not found


2019-05-20T11:13:49Z DEBUG Starting external process

2019-05-20T11:13:49Z DEBUG args=/bin/hostname myclient.example.net

2019-05-20T11:13:49Z DEBUG Process finished, return code=0

2019-05-20T11:13:49Z DEBUG stdout=

2019-05-20T11:13:49Z DEBUG stderr=

2019-05-20T11:13:49Z DEBUG Backing up system configuration file
'/etc/hostname'

2019-05-20T11:13:49Z DEBUG Saving Index File to
'/var/lib/ipa-client/sysrestore/sysrestore.index'

2019-05-20T11:13:49Z DEBUG Saving StateFile to
'/var/lib/ipa-client/sysrestore/sysrestore.state'

2019-05-20T11:13:49Z INFO Synchronizing time with KDC...

2019-05-20T11:13:49Z DEBUG Search DNS for SRV record of _ntp._
udp.example.com

2019-05-20T11:13:50Z DEBUG DNS record not found: NXDOMAIN

2019-05-20T11:13:50Z DEBUG Starting external process

2019-05-20T11:13:50Z DEBUG args=/usr/sbin/ntpdate -s -b -v
myipaserver.example.com

2019-05-20T11:13:50Z DEBUG Process finished, return code=1

2019-05-20T11:13:50Z DEBUG stdout=

2019-05-20T11:13:50Z DEBUG stderr=

2019-05-20T11:13:50Z DEBUG Starting external process

2019-05-20T11:13:50Z DEBUG args=/usr/sbin/ntpdate -s -b -v
myipaserver.example.com

2019-05-20T11:13:50Z DEBUG Process finished, return code=1

2019-05-20T11:13:50Z DEBUG stdout=

2019-05-20T11:13:50Z DEBUG stderr=

2019-05-20T11:13:50Z DEBUG Starting external process

2019-05-20T11:13:50Z DEBUG args=/usr/sbin/ntpdate -s -b -v
myipaserver.example.com

2019-05-20T11:13:50Z DEBUG Process finished, return code=1

2019-05-20T11:13:50Z DEBUG stdout=

2019-05-20T11:13:50Z DEBUG stderr=

2019-05-20T11:13:50Z WARNING Unable to sync time with IPA NTP server,
assuming the time is in sync. Please check that 123 UDP port is opened.

2019-05-20T11:13:50Z DEBUG Starting external process

2019-05-20T11:13:50Z DEBUG args=keyctl get_persistent @s 0

2019-05-20T11:13:50Z DEBUG Process finished, return code=2

2019-05-20T11:13:50Z DEBUG stdout=

2019-05-20T11:13:50Z DEBUG stderr=Unknown command


2019-05-20T11:13:50Z DEBUG Writing Kerberos configuration to /tmp/tmpJ

[Freeipa-users] Re: cert validation failed

[Rob Crittenden via FreeIPA-users]

Petar Kozić via FreeIPA-users wrote:
> Here is the log files. I just want to inform you that I have that
> problem now also on Ubuntu 14.40 and Debian 8.
> On Ubuntu ipa client version is 3.3, maybe problem is there.
> 
> In mean time I enrolled several more Ubuntu 18.04 instances without
> problem. 
> 
> On this Debian 8 and Ubuntu 14.40 I just try with options —ca-cert-file
> which I copied from master but same error.
> 

I have no visibility into what CA file you used but you're missing
either the X3 subca or the X1 root.

You can get them from https://letsencrypt.org/certificates/

Look at the ca.crt you used and see how many certificates are in there.
I'm assuming there is only one. You can try concatenating the X1 and X3
certs into that and things should work.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: cert validation failed

[Petar Kozić via FreeIPA-users]

@Rob, sorry for duplicate mail, I forget to do reply to all


No, there is X1 and X3. I have whole chain in ca.crt

Where you think that I can install this let’s encrypt root on client side,
because on server I already have it in chain?

On IPA I installed on this way.
https://blog.soholabs.org/lets-encrypt-and-the-freeipa-web-gui/

On May 20, 2019 at 3:28:50 PM, Rob Crittenden (rcrit...@redhat.com) wrote:

Petar Kozić via FreeIPA-users wrote:
> Here is the log files. I just want to inform you that I have that
> problem now also on Ubuntu 14.40 and Debian 8.
> On Ubuntu ipa client version is 3.3, maybe problem is there.
>
> In mean time I enrolled several more Ubuntu 18.04 instances without
> problem.
>
> On this Debian 8 and Ubuntu 14.40 I just try with options —ca-cert-file
> which I copied from master but same error.
>

I have no visibility into what CA file you used but you're missing
either the X3 subca or the X1 root.

You can get them from https://letsencrypt.org/certificates/

Look at the ca.crt you used and see how many certificates are in there.
I'm assuming there is only one. You can try concatenating the X1 and X3
certs into that and things should work.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: cert validation failed

[Rob Crittenden via FreeIPA-users]

Petar Kozić via FreeIPA-users wrote:
> @Rob, sorry for duplicate mail, I forget to do reply to all
> 
> 
> No, there is X1 and X3. I have whole chain in ca.crt
> 
> Where you think that I can install this let’s encrypt root on client
> side, because on server I already have it in chain?
> 
> On IPA I installed on this way.
> https://blog.soholabs.org/lets-encrypt-and-the-freeipa-web-gui/

The older ipa-client-install don't handle cert chains well. You can try
to add the roots to the global trust before running the installer via:

$ sudo cp ca.crt /usr/local/share/ca-certificates/
$ sudo update-ca-certificates

rob

> 
> On May 20, 2019 at 3:28:50 PM, Rob Crittenden (rcrit...@redhat.com
> ) wrote:
> 
>> Petar Kozić via FreeIPA-users wrote:
>> > Here is the log files. I just want to inform you that I have that
>> > problem now also on Ubuntu 14.40 and Debian 8.
>> > On Ubuntu ipa client version is 3.3, maybe problem is there.
>> >  
>> > In mean time I enrolled several more Ubuntu 18.04 instances without
>> > problem. 
>> >  
>> > On this Debian 8 and Ubuntu 14.40 I just try with options —ca-cert-file
>> > which I copied from master but same error.
>> >  
>>
>> I have no visibility into what CA file you used but you're missing
>> either the X3 subca or the X1 root.
>>
>> You can get them from https://letsencrypt.org/certificates/
>>
>> Look at the ca.crt you used and see how many certificates are in there.
>> I'm assuming there is only one. You can try concatenating the X1 and X3
>> certs into that and things should work.
>>
>> rob
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: cert validation failed

[Petar Kozić via FreeIPA-users]

I just try that:

cp ca.crt /usr/local/share/ca-certificates/
update-ca-certificates

Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d
updates of cacerts keystore disabled.
done.

Looks like update something, but again same error. In above command I
copied ca.crt from IPA if you think on that.
Thank you on your time.

On May 20, 2019 at 4:03:32 PM, Rob Crittenden (rcrit...@redhat.com) wrote:

Petar Kozić via FreeIPA-users wrote:
> @Rob, sorry for duplicate mail, I forget to do reply to all
>
>
> No, there is X1 and X3. I have whole chain in ca.crt
>
> Where you think that I can install this let’s encrypt root on client
> side, because on server I already have it in chain?
>
> On IPA I installed on this way.
> https://blog.soholabs.org/lets-encrypt-and-the-freeipa-web-gui/

The older ipa-client-install don't handle cert chains well. You can try
to add the roots to the global trust before running the installer via:

$ sudo cp ca.crt /usr/local/share/ca-certificates/
$ sudo update-ca-certificates

rob

>
> On May 20, 2019 at 3:28:50 PM, Rob Crittenden (rcrit...@redhat.com
> ) wrote:
>
>> Petar Kozić via FreeIPA-users wrote:
>> > Here is the log files. I just want to inform you that I have that
>> > problem now also on Ubuntu 14.40 and Debian 8.
>> > On Ubuntu ipa client version is 3.3, maybe problem is there.
>> >
>> > In mean time I enrolled several more Ubuntu 18.04 instances without
>> > problem.
>> >
>> > On this Debian 8 and Ubuntu 14.40 I just try with options
—ca-cert-file
>> > which I copied from master but same error.
>> >
>>
>> I have no visibility into what CA file you used but you're missing
>> either the X3 subca or the X1 root.
>>
>> You can get them from https://letsencrypt.org/certificates/
>>
>> Look at the ca.crt you used and see how many certificates are in there.
>> I'm assuming there is only one. You can try concatenating the X1 and X3
>> certs into that and things should work.
>>
>> rob
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: cert validation failed

[Rob Crittenden via FreeIPA-users]

Petar Kozić wrote:
> I just try that:
> 
> cp ca.crt /usr/local/share/ca-certificates/
> update-ca-certificates
> 
> Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
> Running hooks in /etc/ca-certificates/update.d
> updates of cacerts keystore disabled.
> done.
> 
> Looks like update something, but again same error. In above command I
> copied ca.crt from IPA if you think on that.
> Thank you on your time.

That's about the extent of my Ubuntu knowledge.

It's hard to parse the output. Was that one file added or one
certificate added? LE definitely has a chain.

You should be able to independently confirm that the trust is ok using
something like curl:

$ curl https://ipa.example.com/ipa

If the connection fails then the right LE roots are not available on the
system.

rob

> 
> On May 20, 2019 at 4:03:32 PM, Rob Crittenden (rcrit...@redhat.com
> ) wrote:
> 
>> Petar Kozić via FreeIPA-users wrote:
>> > @Rob, sorry for duplicate mail, I forget to do reply to all
>> >  
>> >  
>> > No, there is X1 and X3. I have whole chain in ca.crt
>> >  
>> > Where you think that I can install this let’s encrypt root on client
>> > side, because on server I already have it in chain?
>> >  
>> > On IPA I installed on this way.
>> > https://blog.soholabs.org/lets-encrypt-and-the-freeipa-web-gui/
>>
>> The older ipa-client-install don't handle cert chains well. You can try
>> to add the roots to the global trust before running the installer via:
>>
>> $ sudo cp ca.crt /usr/local/share/ca-certificates/
>> $ sudo update-ca-certificates
>>
>> rob
>>
>> >  
>> > On May 20, 2019 at 3:28:50 PM, Rob Crittenden (rcrit...@redhat.com 
>> > 
>> > >) wrote:
>> >  
>> >> Petar Kozić via FreeIPA-users wrote:
>> >> > Here is the log files. I just want to inform you that I have that
>> >> > problem now also on Ubuntu 14.40 and Debian 8.
>> >> > On Ubuntu ipa client version is 3.3, maybe problem is there.
>> >> >   
>> >> > In mean time I enrolled several more Ubuntu 18.04 instances without
>> >> > problem. 
>> >> >   
>> >> > On this Debian 8 and Ubuntu 14.40 I just try with options —ca-cert-file
>> >> > which I copied from master but same error.
>> >> >   
>> >>
>> >> I have no visibility into what CA file you used but you're missing
>> >> either the X3 subca or the X1 root.
>> >>
>> >> You can get them from https://letsencrypt.org/certificates/
>> >>
>> >> Look at the ca.crt you used and see how many certificates are in there.
>> >> I'm assuming there is only one. You can try concatenating the X1 and X3
>> >> certs into that and things should work.
>> >>
>> >> rob
>> >  
>> >  
>> > ___
>> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> 
>> > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>> 
>> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives: 
>> > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>>
>> >  
>>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: cert validation failed

[Petar Kozić via FreeIPA-users]

Thank you very much for everything.
I tried curl and curl on https:// works, a get html response with whole
body





IPA: Identity Policy Audit

[Freeipa-users] secure freeipa exposed to internet

[Stepan Vardanyan via FreeIPA-users]

Hello,

I've proposed to migrate from OpenLDAP to FreeIPA solution in my organization 
because the former did not met our requirements as we moving to Single Sign On. 
We migrated to FreeIPA but set it up with internal DNS name. This was dumb 
decision as we have a lot of external hosts in AWS and other datacenters which 
we want to join to our FreeIPA for authentication with one credential and 
utilize policies (HBAC, sudoers) easily and centrally.

We found that there is two solutions: 
- setup tunnels between AWS and datacenters for making our DNS zone and FreeIPA 
servers available;
- redeploy whole FreeIPA with external DNS name and expose FreeIPA servers to 
Internet.
We end up with second option because first one is very complex, but second 
option make us think about security.
What came to mind is:
- disable anonymous bind;
- prohibit unencrypted traffic and improve communications security by using 
options: nsslapd-minssf=128, nsslapd-require-secure-binds=on, 
sslVersionMin=TLS1.1.

So, there is several questions:
1) Is there anything else from security perspective that we should care, 
configure properly (Kerberos DC for example)?
2) We want to share with users only one Web service from specific replica so 
users will not cause replication conflicts by modifying entries in other 
replicas. Is it ok if we close web ports (80, 443) only to localhost on other 
replicas and leave all other ports on all replicas opened to internet 
(389,636,88,464)?
3) How secure and strong is default SASL/GSSAPI replication mechanism? I've 
noticed that traffic is encrypted but can be decrypted by using servers 
kerberos keytab
4) Overall, even with all previous concerns taken into account cared is it 
proper to open FreeIPA to internet? This is kinda rhetorical question as we see 
that this is only choice for us but just want to hear some advices, expert 
vision.

P.S. We don't utilize FreeIPA internal DNS service. DNS is configured on 
external hosts

Thanks in advance.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: secure freeipa exposed to internet

[John Keates via FreeIPA-users]

I would never run FreeIPA over the public internet, bad idea. It’s not as bad 
as running AD over the internet, but it’s getting pretty close.

Run servers in all zones/regions and have those servers talk to each other 
(tunnels).
Stuff inside a zone will do a discovery and find the servers that work, which 
would be the local servers as the rest isn’t reachable.

Regarding DNS: would not do external servers, just use the internal DNS and add 
conditional forwarders or subzone delegation. (either way, IPA-to-Zone or 
Zone-to-IPA, as long as it can resolve)
Problem with ’special’ setups like what you’re describing is that it’s harder 
to support, upgrade, troubleshoot etc. It also usually means the infrastructure 
isn’t designed correctly.

John

> On 20 May 2019, at 20:11, Stepan Vardanyan via FreeIPA-users 
>  wrote:
> 
> Hello,
> 
> I've proposed to migrate from OpenLDAP to FreeIPA solution in my organization 
> because the former did not met our requirements as we moving to Single Sign 
> On. We migrated to FreeIPA but set it up with internal DNS name. This was 
> dumb decision as we have a lot of external hosts in AWS and other datacenters 
> which we want to join to our FreeIPA for authentication with one credential 
> and utilize policies (HBAC, sudoers) easily and centrally.
> 
> We found that there is two solutions: 
> - setup tunnels between AWS and datacenters for making our DNS zone and 
> FreeIPA servers available;
> - redeploy whole FreeIPA with external DNS name and expose FreeIPA servers to 
> Internet.
> We end up with second option because first one is very complex, but second 
> option make us think about security.
> What came to mind is:
> - disable anonymous bind;
> - prohibit unencrypted traffic and improve communications security by using 
> options: nsslapd-minssf=128, nsslapd-require-secure-binds=on, 
> sslVersionMin=TLS1.1.
> 
> So, there is several questions:
> 1) Is there anything else from security perspective that we should care, 
> configure properly (Kerberos DC for example)?
> 2) We want to share with users only one Web service from specific replica so 
> users will not cause replication conflicts by modifying entries in other 
> replicas. Is it ok if we close web ports (80, 443) only to localhost on other 
> replicas and leave all other ports on all replicas opened to internet 
> (389,636,88,464)?
> 3) How secure and strong is default SASL/GSSAPI replication mechanism? I've 
> noticed that traffic is encrypted but can be decrypted by using servers 
> kerberos keytab
> 4) Overall, even with all previous concerns taken into account cared is it 
> proper to open FreeIPA to internet? This is kinda rhetorical question as we 
> see that this is only choice for us but just want to hear some advices, 
> expert vision.
> 
> P.S. We don't utilize FreeIPA internal DNS service. DNS is configured on 
> external hosts
> 
> Thanks in advance.
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Mapping freeipa's groups over AD

[Lucas Diedrich via FreeIPA-users]

Hello guys, i found lots of tutorials helping on how to map AD (Active
Directory) users over Freeipa as seen here:
https://jamalshahverdiev.wordpress.com/2017/09/09/integration-freeipa-in-centos7-to-microsoft-active-directory/
 and
http://prolinuxhub.com/integrate-freeipa-with-windows-2016-active-directory/

My question is, can i make the other way around? I wan't to map the Freeipa
Group (Admin) as admin over the Active Directory. Can i?

I've already setup an transient two-way trust between both, authentication
works nice for freeipa users over AD. I just want to setup admin users for
the windows workstations.

Thanks.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: secure freeipa exposed to internet

[Step Vardanyan via FreeIPA-users]

Thanks for you reply John.

> I would never run FreeIPA over the public internet, bad idea. It’s not as
bad as running AD over the internet, but it’s getting pretty close.
FreeIPA is based on 389ds and MIT kerberos. 389ds has risks with MITM
attacks (capture plain text traffic) which can be avoided by forcing TLS
and anonymous bind (which can be disabled), kerberos according to docs
designed to work via untrusted networks. So, what are the risks from
technical side?

> Run servers in all zones/regions and have those servers talk to each
other (tunnels).
> Stuff inside a zone will do a discovery and find the servers that work,
which would be the local servers as the rest isn’t reachable.
This either requires configuring DNS forwarding on local DNS or manual
filling of replica list in every host, both of which are headache. For us
it doesn't work also because most of our external hosts are in AWS and
Route53 (AWS DNS service) doesn't have forwarding functionality. The tricky
option is to create local DNS zone in every DC with exact same zone used in
FreeIPA deployment but this is dirty and hard maintainable (e.g. every time
we add/remove replica we should modify _ldap._tcp records in every
datacenter). Ideally, we want DNS zone controlled centrally.

> Regarding DNS: would not do external servers, just use the internal DNS
and add conditional forwarders or subzone delegation. (either way,
IPA-to-Zone or Zone-to-IPA, as long as it can resolve)
I'm not sure but in doubt if it works. I've tried to bind external DNS name
to replica with internal DNS hostname and it didn't work because hostname
operated while install is hardcoding in FreeIPA. In other words when you
try access in browser external.example.com in redirects you to
internal.example.local which is not resolvable outside of infrastructure. I
wanted to bind external name for sharing web interface of FreeIPA with
users so they can change their password, set SSH keys by themself, etc. See
details about hardcode here https://pagure.io/freeipa/issue/7479

> Problem with ’special’ setups like what you’re describing is that it’s
harder to support, upgrade, troubleshoot etc. It also usually means the
infrastructure isn’t designed correctly.
Our infrastructure is not spreaded through different regions as you may
understood. We are software development company and we host our
applications for clients in cloud services as AWS. We utilized FreeIPA
because we want to avoid bunch of credentials (use only LDAP creds on all
hosts) and centrally manage HBAC, sudo access to hosts running our
applications. Honestly, these external hosts are the reason why we thought
to expose FreeIPA and hence care about security.

On Tue, 21 May 2019 at 00:16, John Keates  wrote:

> I would never run FreeIPA over the public internet, bad idea. It’s not as
> bad as running AD over the internet, but it’s getting pretty close.
>
> Run servers in all zones/regions and have those servers talk to each other
> (tunnels).
> Stuff inside a zone will do a discovery and find the servers that work,
> which would be the local servers as the rest isn’t reachable.
>
> Regarding DNS: would not do external servers, just use the internal DNS
> and add conditional forwarders or subzone delegation. (either way,
> IPA-to-Zone or Zone-to-IPA, as long as it can resolve)
> Problem with ’special’ setups like what you’re describing is that it’s
> harder to support, upgrade, troubleshoot etc. It also usually means the
> infrastructure isn’t designed correctly.
>
> John
>
> > On 20 May 2019, at 20:11, Stepan Vardanyan via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> >
> > Hello,
> >
> > I've proposed to migrate from OpenLDAP to FreeIPA solution in my
> organization because the former did not met our requirements as we moving
> to Single Sign On. We migrated to FreeIPA but set it up with internal DNS
> name. This was dumb decision as we have a lot of external hosts in AWS and
> other datacenters which we want to join to our FreeIPA for authentication
> with one credential and utilize policies (HBAC, sudoers) easily and
> centrally.
> >
> > We found that there is two solutions:
> > - setup tunnels between AWS and datacenters for making our DNS zone and
> FreeIPA servers available;
> > - redeploy whole FreeIPA with external DNS name and expose FreeIPA
> servers to Internet.
> > We end up with second option because first one is very complex, but
> second option make us think about security.
> > What came to mind is:
> > - disable anonymous bind;
> > - prohibit unencrypted traffic and improve communications security by
> using options: nsslapd-minssf=128, nsslapd-require-secure-binds=on,
> sslVersionMin=TLS1.1.
> >
> > So, there is several questions:
> > 1) Is there anything else from security perspective that we should care,
> configure properly (Kerberos DC for example)?
> > 2) We want to share with users only one Web service from specific
> replica so users will not cause replication conflicts by

[Freeipa-users] Re: secure freeipa exposed to internet

[Natxo Asenjo via FreeIPA-users]

hi,

On Mon, May 20, 2019 at 8:11 PM Stepan Vardanyan via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hello,
>
> I've proposed to migrate from OpenLDAP to FreeIPA solution in my
> organization because the former did not met our requirements as we moving
> to Single Sign On. We migrated to FreeIPA but set it up with internal DNS
> name. This was dumb decision as we have a lot of external hosts in AWS and
> other datacenters which we want to join to our FreeIPA for authentication
> with one credential and utilize policies (HBAC, sudoers) easily and
> centrally.
>
> We found that there is two solutions:
> - setup tunnels between AWS and datacenters for making our DNS zone and
> FreeIPA servers available;
> - redeploy whole FreeIPA with external DNS name and expose FreeIPA servers
> to Internet.
>
We end up with second option because first one is very complex, but second
> option make us think about security.
>

A vpn between data centers is a best practice. It does not have to be very
complex or expensive, openvpn comes to mind, but if you have no experience
with vpns I can understand that they can look very hard.


> What came to mind is:
> - disable anonymous bind;
> - prohibit unencrypted traffic and improve communications security by
> using options: nsslapd-minssf=128, nsslapd-require-secure-binds=on,
> sslVersionMin=TLS1.1.
>

This is ok, I would probably bump tls to 1.2 but you may have applications
that do not work properly with that so you know better ;-)

So, there is several questions:
> 1) Is there anything else from security perspective that we should care,
> configure properly (Kerberos DC for example)?
>

Take a look at the 'Security hardening' section of the documentation:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/p.security-hardening

2) We want to share with users only one Web service from specific replica
> so users will not cause replication conflicts by modifying entries in other
> replicas. Is it ok if we close web ports (80, 443) only to localhost on
> other replicas and leave all other ports on all replicas opened to internet
> (389,636,88,464)?
>

This is a bit unclear. All objects in the ldap servers are replicated (all
ldap servers are masters).

You do not need to open the whole internet to your environmnent, you can
firewall everything but the hosts that need authenticating/authorizing.

I would block internet wide connections to unencrypted protocols, so no
389, just ldaps/636. I know you can use starttls, but why bother. You need
http for crl and ocsp, but the rest is https.


3) How secure and strong is default SASL/GSSAPI replication mechanism? I've
> noticed that traffic is encrypted but can be decrypted by using servers
> kerberos keytab
>

If you have the keytab, you have the password. This is normal. Secure the
keytab. The replication is as secure as you have configured your directory
server component, I guess. If you set sslVersionMin: TLS1.2, then it's
pretty secure. Remember, security is layered, so restrict ldap traffic to
the ldap servers only to trusted networks (most firewalls can be scripted
nowadays).


4) Overall, even with all previous concerns taken into account cared is it
> proper to open FreeIPA to internet? This is kinda rhetorical question as we
> see that this is only choice for us but just want to hear some advices,
> expert vision.
>

With proper care it should be safe. I would use 2FA (otp and/or pkinit),
both work really well with freeipa for any internet facing service, have
the environment properly pentested and enable a central logging mechanism
that gets audited regularly.

HTH.

-- 
regards,
Natxo
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: secure freeipa exposed to internet

[Robbie Harwood via FreeIPA-users]

Stepan Vardanyan via FreeIPA-users
 writes:

> Hello,
>
> I've proposed to migrate from OpenLDAP to FreeIPA solution in my
>organization because the former did not met our requirements as we
>moving to Single Sign On. We migrated to FreeIPA but set it up with
>internal DNS name. This was dumb decision as we have a lot of external
>hosts in AWS and other datacenters which we want to join to our FreeIPA
>for authentication with one credential and utilize policies (HBAC,
>sudoers) easily and centrally.
>
> We found that there is two solutions: 
> - setup tunnels between AWS and datacenters for making our DNS zone and 
> FreeIPA servers available;
> - redeploy whole FreeIPA with external DNS name and expose FreeIPA servers to 
> Internet.
> We end up with second option because first one is very complex, but second 
> option make us think about security.
> What came to mind is:
> - disable anonymous bind;
> - prohibit unencrypted traffic and improve communications security by using 
> options: nsslapd-minssf=128, nsslapd-require-secure-binds=on, 
> sslVersionMin=TLS1.1.
>
> So, there is several questions:
>
> 1) Is there anything else from security perspective that we should
> care, configure properly (Kerberos DC for example)?

Kerberos is fine to expose.  If you are concerned, it's possible to
limit the surface with kdcproxy - IPA already sets this up - and then
block port 88.

The main problem, though, with exposing services to the public internet
is handling unexpected load.  If you can't handle it, then your system
effectively goes down under DOS.

> 3) How secure and strong is default SASL/GSSAPI replication mechanism?
> I've noticed that traffic is encrypted but can be decrypted by using
> servers kerberos keytab

This is how Kerberos works, yes.  A keytab is a bit like the private key
on a certificate (in this case).  Keep your keytabs safe :)

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: OTP check via API

[Robbie Harwood via FreeIPA-users]

Adam Bishop via FreeIPA-users 
writes:

> Is there an API endpoint I can use to perform OTP verification without
> the users password (i.e. just with their DN or uid)?
>
> I've got a non-web application with its own authentication system that
> I'd like to add MFA to, and I'd rather avoid copying the OTP secrets
> to it or re-writing the application.

Not by default.  IPA isn't a full RADIUS responder, but ipa-otpd speaks
enough of the protocol to verify the concatenation of password + OTP
code.  It accomplishes this by performing an LDAP bind, for which it
needs the user's password.  This information isn't otherwise exposed.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] AD->IPA Synchronisation: Staged versus Active users

[Robert Sturrock via FreeIPA-users]

Hi All.

I’m exploring the use of IPA in a synchronisation (rather than trust) 
arrangement with AD, as this fits a particular use-case we have here quite well.

Our AD is very large, so a large number of users are synchronised into IPA and 
they come across by default as ‘Disabled’.  This is fine - an administrator can 
easily enable those who need access.

However, the users all show up as ‘Active users’, rather than ‘Stage users’.  
But it would be much better if they were ‘Stage users’ to start with, and 
needed to be explicitly activated before moving into ‘Active users’.

It seems that IPA doesn’t work this way in a synchronisation agreement?  Is 
there any way to configure the system so that it does?

Regards,

Robert.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org