[Freeipa-users] Re: not thinking with the design of bind-dyndb-ldap

[Simo Sorce via FreeIPA-users]

This language is completely unacceptable.

You have been put in permanent moderation.

You can receive messages, but anything you send will be held in
moderation and may or not be acted upon as time permits by the
moderators.

You can appeal this decision by writing to the list owners.
But I warn you that using similar language in any communication will
simply cause you to be completely banned without a reply.

Learn to live a civil life in person and online.
Thank you,

Simo, on behalf of the project moderators.

On Thu, 2023-09-21 at 11:41 +, Marc via FreeIPA-users wrote:
[..]

-- 
Simo Sorce,
DE @ RHEL Crypto Team,
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Do keytabs expire?

[Simo Sorce via FreeIPA-users]

On Wed, 2023-06-07 at 10:36 +0200, Ronald Wimmer via FreeIPA-users
wrote:
> On 19.09.17 12:07, Alexander Bokovoy wrote:
> > On ti, 19 syys 2017, Ronald Wimmer wrote:
> > > On 2017-09-19 11:53, Alexander Bokovoy wrote:
> > > > [...]
> > > > Please spend some time reading the documentation. It is vast and has a
> > > > lot of answers to questions people keep asking on these lists.
> > > 
> > > I've already spent some time reading the documentation. Since
> > > "ipa-getkeytab" worked I was not aware of the fact that "ipa-getkeytab
> > > -r" would need:
> > > 
> > > ipa service-allow-retrieve-keytab HTTP/cluster.idm.example.com 
> > > --hosts={node01.idm.example.com,node02.idm.example.com}
> > That's why I gave you these links as you have obviously didn't read
> > them.
> > 
> > Glad that it works now.
> 
> As we ran into this problem again it should be mentioned that restarting 
> gssproxy.service can be necessary.
> 
> In our case Apache was looking for a KVNO 1 whereas the actual file did 
> already have version number 4.


FWIW, gssapi should pick up new keys in keytabs without the need to
restart.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Error replacing a replica with CentOS Stream 9

[Simo Sorce via FreeIPA-users]

On Wed, 2021-12-15 at 10:49 +0200, Alexander Bokovoy via FreeIPA-users
wrote:
> Hi Antoine,
> 
> On ke, 15 joulu 2021, Antoine Gatineau via FreeIPA-users wrote:
> > Hi,
> > 
> > This message was probably missed in all the log4shell exchanges.
> > Any hint on how to rebuild the RA certificate with a newer algorythm before 
> > migrating to Centos Stream 9?
> 
> The error you have is this:
> 
> --
> Error outputting keys
> andcertificates\\n80EB2D6B5D7F:error:0308010C:digital envelope
> routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:346:Global
> default library context, Algorithm (RC2-40-CBC : 0), Properties()
> --
> 
> This is produced by an OpenSSL 3.0.0 which does not have support for
> legacy ciphers by default. This legacy cipher (RC2-40-CBC) was used by
> PKI releases prior to
> https://bugzilla.redhat.com/show_bug.cgi?id=1975406 was fixed.
> 
> Since in the CA replica installation case we get RA agent key transferred
> securely from CA master, this key would be the one encrypted on CentOS
> Stream 8 and would still use RC2-40-CBC, thus making it impossible to
> consume on OpenSSL 3.0.0-enabled system.
> 
> I think we need a bug against IPA to re-encrypt this key on 'earlier'
> system before 'newer' one could be deployed. Adding Christian for
> visibility.
> 
> Could you please open one?

Worst case you can re-enble the legacy provider in code, but I think a
migration/upgrade script is probably a better idea.

> 
> 
> > 
> > Many thanks
> > 
> > On Sat, 2021-12-11 at 16:56 +0100, Antoine Gatineau via FreeIPA-users wrote:
> > > 
> > > Hello,
> > > 
> > > I have currently a 2 node cluster running on CentOS Stream 8. In order to 
> > > upgrade to CentOS 9, I have removed one of the replica from the
> > > configuration, installed a fresh centos stream 9 and run 
> > > ipa-replica-install.
> > > It fails with this error (full log attached):
> > >   [22/29]: Importing RA key
> > > Error storing key "keys/ra/ipaCert": CalledProcessError(Command 
> > > ['/usr/libexec/ipa/custodia/ipa-custodia-ra-agent', '--import', '-']
> > > returned non-zero exit status 1: 'Traceback (most recent call last):\n  
> > > File "/usr/libexec/ipa/custodia/ipa-custodia-ra-agent", line 8, in
> > > \n    main(ra_agent_parser())\n  File 
> > > "/usr/lib/python3.9/site-packages/ipaserver/secrets/handlers/pemfile.py", 
> > > line 114, in
> > > main\n
> > > common.main(parser, export_key, import_key)\n  File 
> > > "/usr/lib/python3.9/site-packages/ipaserver/secrets/handlers/common.py", 
> > > line 73, in
> > > main\n    func(args, tmpdir, **kwargs)\n  File 
> > > "/usr/lib/python3.9/site-packages/ipaserver/secrets/handlers/pemfile.py", 
> > > line 69, in
> > > import_key\n    ipautil.run(cmd, umask=0o027)\n  File 
> > > "/usr/lib/python3.9/site-packages/ipapython/ipautil.py", line 598, in 
> > > run\n    raise
> > > CalledProcessError(\nipapython.ipautil.CalledProcessError: 
> > > CalledProcessError(Command [\'/usr/bin/openssl\', \'pkcs12\', \'-in\',
> > > \'/tmp/tmp7jrs5dqp/import.p12\', \'-clcerts\', \'-nokeys\', \'-out\', 
> > > \'/var/lib/ipa/ra-agent.pem\', \'-password\',
> > > \'file:/tmp/tmp7jrs5dqp/passwd\'] returned non-zero exit status 1: 
> > > \'Error outputting keys and
> > > certificates\\n80EB2D6B5D7F:error:0308010C:digital envelope
> > > routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:346:Global
> > >  default library context, Algorithm (RC2-40-CBC : 0),
> > > Properties ()\\n\')\n')
> > >   [error] FileNotFoundError: [Errno 2] No such file or directory: 
> > > '/var/lib/ipa/ra-agent.key'
> > > Your system may be partly configured.
> > > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > > 
> > > What can I do to make this upgrade work?
> > > Looks like an unsupported algorithm for the RA key. I tried "sudo 
> > > update-crypto-policies --set LEGACY" without success.
> > > 
> > > 
> > > Thank you
> > > ___
> > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> > > Do not reply to spam on the list, report it: 
> > > https://pagure.io/fedora-infrastructure
> > 
> > -- 
> > Antoine GatineauFreelance IT Consultant
> > Phone: +32 499 50 80 04
> > Web: https://infra-monkey.com
> > 
> > ___
> > 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: 
> > 

[Freeipa-users] Re: FreeIPA and FIPS

[Simo Sorce via FreeIPA-users]

Hi Steve,

On Mon, 2021-04-19 at 19:08 +, Steve Reed via FreeIPA-users wrote:
> Hi Stephen,
> 
> True.  I understand that, but I think we are getting off track to my
> original question.  Can you run a FIPS FreeIPA server and still have
> the clients work with it?  It't not necessarily required to have the
> clients FIPS compliant, but the server must since it has to do the
> encryption for data that it stores.

Yes you can run a server in FIPS mode, and clients will generally talk
to it just fine. FIPS mode in RHEL simply reduces the set of available
algorithms,so clients have less to chose from but will work just fine.

The caveat is if you have non-RHEL clients that are either very old, or
somewhat "special", and support only a subset of (old/different)
algorithms that are not supported by the server in FIPs mode.

So the answer is generally "yes with some caveats".

Note that this caveats are also valid in general for running on RHEL
where we apply somewhat stringent crypto policies to avoid old and weak
protocols by default.

> And I appreciate that everyone is trying to save me some time, but it
> has been decided that we will use FIPS unless it proves not
> beneficial.

Just a note for everyone looking at this thread.
FIPS mode can be used at any time without restriction, so you are
welcome to use it. Many chose to use FIPS mode to make sure only tested
and approved algorithms are used.

However, FIPS compliance is technically possible only with certified
modules. And Red Hat certifies exclusively RHEL binary builds (I know
because I do that). You can check the certificates on the CMVP website
and the related Security Policy documents for more details. 

CentOS (or any other rebuild) builds are not covered by Red Hat
Certificates and I am not aware of anyone else certifying CentOS
binaries either.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: migrating NIS passwords to FreeIPA in Fedora 33 with {CRYPT} and RH sample nis-users.sh script

[Simo Sorce via FreeIPA-users]

On Wed, 2021-02-03 at 12:34 -0500, Robert Kudyba via FreeIPA-users
wrote:
> On Wed, Feb 3, 2021 at 12:18 PM Jochen Kellner  wrote:
> 
> > Robert Kudyba via FreeIPA-users 
> > writes:
> > 
> > > So now I put:
> > > ipa user-add $username --first=$first --last=$last \
> > >  --setattr userpassword='{CRYPT}$password1' --gidnumber=$gid
> > 
> > Try:
> >   --setattr "userpassword={CRYPT}$password1" --gidnumber=$gid
> > 
> 
> Nice, that worked as well as:
>--setattr userpassword="{CRYPT}$password1" --gidnumber=$gid
> 
> Now any idea why the original  '$gecos' inserts the actual string  $gecos
> into FreeIPA/LDAP?

It's a shell issue, single quotes prevents any argument expansion, use
double quotes.

> Logs also spit out this warning after every user is added:
> Failed to set perms (3140) on file (/run/ipa/ccaches/ad...@ourdomain.edu)!,
> referer: https://oudomain.edu/ipa/xml
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: POSIX ids of all AD users

[Simo Sorce via FreeIPA-users]

On Fri, 2020-10-02 at 12:27 +0200, Ronald Wimmer via FreeIPA-users
wrote:
> How could I possibly find the POSIX ids of all mapped Active Directory 
> users?
> 
> I do neither see them in LDAP nor do I find them with IPA user find.

They are in AD, query AD please.

The only other option is to use a command like: id , but that
requires knowledge of each AD username you care for.

Keep in mind IPA is not a caching LDAP server, that's not its role, its
role is to provide the means to establish a point of trust between the
two worlds, so that AD clients can use services hosted in the IPA
domain servers.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: [offlist] Re: Re: Modify LDAP/HTTP to add alternative names

[Simo Sorce via FreeIPA-users]

On Thu, 2020-10-01 at 11:46 +1000, Fraser Tweedale wrote:
> On Wed, Sep 30, 2020 at 09:43:29AM -0400, Simo Sorce wrote:
> > On Wed, 2020-09-30 at 16:04 +1000, Fraser Tweedale wrote:
> > > On Tue, Sep 29, 2020 at 09:44:16AM -0400, Simo Sorce via FreeIPA-users 
> > > wrote:
> > > > On Tue, 2020-09-29 at 14:01 +0200, Christian Heimes via FreeIPA-users
> > > > wrote:
> > > > > On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
> > > > > > On Thu, Sep 24, 2020 at 02:15:11PM -, Willie Lima via 
> > > > > > FreeIPA-users wrote:
> > > > > > > Hi guys,
> > > > > > > 
> > > > > > > I have 12 freeipa servers deployed with integrated DNS and CA
> > > > > > > (realm and domain int.example.com).
> > > > > > > 
> > > > > > > I would like to make a DNS round-robin, for instance: request
> > > > > > > ldap.int.example.com and forward for one of the servers and also
> > > > > > > an external domain ldap.example.com
> > > > > > > 
> > > > > > > The problem is with the certificate, the TLS handshake fails
> > > > > > > because there's no alternative name with ldap.int.example.com or
> > > > > > > ldap.example.com.
> > > > > > > 
> > > > > > > I read the redhat documentation about certificate manipulation,
> > > > > > > but I got very confused in fact how it works.
> > > > > > > 
> > > > > > > How can I do that? Are there another recommendation?
> > > > > > > 
> > > > > > Hello Willie,
> > > > > > 
> > > > > > It is not supported.  With some effort you could create the
> > > > > > necessary objects and relationship in FreeIPA to permit issuance of
> > > > > > such a certificate, then you could modify the certmonger tracking
> > > > > > request (on every server) to request a certificate with those SANs.
> > > > > > But the tracking request modifications would eventually be lost
> > > > > > during ipa-server-upgrade (FreeIPA will see that the tracking
> > > > > > request doesn't match expectations and replace it).
> > > > > > 
> > > > > > A possible alternative approach (I haven't tested it yet) is if you
> > > > > > discover the LDAP servers via SRV records, i.e.
> > > > > > _ldaps._tcp.int.example.com.  This would give "round robin"
> > > > > > (actually service weighting but you get the idea) to all the LDAP
> > > > > > servers in the topology.  I'd have to check if openldap client
> > > > > > performs certificate validation properly in this scenario though.
> > > > > 
> > > > > OpenLDAP does not support SRV lookup. The python-ldap feature request
> > > > > https://github.com/python-ldap/python-ldap/issues/178 contains more
> > > > > information on the topic. I have recently implemented a new feature 
> > > > > that
> > > > > would allow you to implement SRV lookup more efficiently.
> > > > > 
> > > > > TLS hostname verification is not an issue. A client does not directly
> > > > > use the SRV address. Instead you perform a SRV lookup which gives you 
> > > > > a
> > > > > list of hostnames with weights and priorities. An LDAP client connects
> > > > > to the hostnames and uses the hostname to verify the identity of the
> > > > > certificate.
> > > > 
> > > > This is cool but also problematic wrt security unless DNSSEC is used,
> > > > as it is relatively easy to spoof a SRV record reply to point the
> > > > client to an attacker controlled server.
> > > > 
> > > > Simo.
> > > > 
> > > 
> > > SRVName in the certificate mitigates this security issue, if the
> > > client validates SRVName per RFC 6125.  But FreeIPA does not yet
> > > support issuing certs with SRVName.  I have an experimental branch
> > > but there are some issues to resolve.
> > 
> > Would be really cool to support indeed, as that definitely resolve
> > issues as long as the CA properly verifies ownership of the SRV Name
> > before granting it in certs.
> > Any thought on how we could support this with ACME ?
> > 
> 

[Freeipa-users] Re: [offlist] Re: Re: Modify LDAP/HTTP to add alternative names

[Simo Sorce via FreeIPA-users]

On Wed, 2020-09-30 at 16:04 +1000, Fraser Tweedale wrote:
> On Tue, Sep 29, 2020 at 09:44:16AM -0400, Simo Sorce via FreeIPA-users wrote:
> > On Tue, 2020-09-29 at 14:01 +0200, Christian Heimes via FreeIPA-users
> > wrote:
> > > On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
> > > > On Thu, Sep 24, 2020 at 02:15:11PM -, Willie Lima via FreeIPA-users 
> > > > wrote:
> > > > > Hi guys,
> > > > > 
> > > > > I have 12 freeipa servers deployed with integrated DNS and CA
> > > > > (realm and domain int.example.com).
> > > > > 
> > > > > I would like to make a DNS round-robin, for instance: request
> > > > > ldap.int.example.com and forward for one of the servers and also
> > > > > an external domain ldap.example.com
> > > > > 
> > > > > The problem is with the certificate, the TLS handshake fails
> > > > > because there's no alternative name with ldap.int.example.com or
> > > > > ldap.example.com.
> > > > > 
> > > > > I read the redhat documentation about certificate manipulation,
> > > > > but I got very confused in fact how it works.
> > > > > 
> > > > > How can I do that? Are there another recommendation?
> > > > > 
> > > > Hello Willie,
> > > > 
> > > > It is not supported.  With some effort you could create the
> > > > necessary objects and relationship in FreeIPA to permit issuance of
> > > > such a certificate, then you could modify the certmonger tracking
> > > > request (on every server) to request a certificate with those SANs.
> > > > But the tracking request modifications would eventually be lost
> > > > during ipa-server-upgrade (FreeIPA will see that the tracking
> > > > request doesn't match expectations and replace it).
> > > > 
> > > > A possible alternative approach (I haven't tested it yet) is if you
> > > > discover the LDAP servers via SRV records, i.e.
> > > > _ldaps._tcp.int.example.com.  This would give "round robin"
> > > > (actually service weighting but you get the idea) to all the LDAP
> > > > servers in the topology.  I'd have to check if openldap client
> > > > performs certificate validation properly in this scenario though.
> > > 
> > > OpenLDAP does not support SRV lookup. The python-ldap feature request
> > > https://github.com/python-ldap/python-ldap/issues/178 contains more
> > > information on the topic. I have recently implemented a new feature that
> > > would allow you to implement SRV lookup more efficiently.
> > > 
> > > TLS hostname verification is not an issue. A client does not directly
> > > use the SRV address. Instead you perform a SRV lookup which gives you a
> > > list of hostnames with weights and priorities. An LDAP client connects
> > > to the hostnames and uses the hostname to verify the identity of the
> > > certificate.
> > 
> > This is cool but also problematic wrt security unless DNSSEC is used,
> > as it is relatively easy to spoof a SRV record reply to point the
> > client to an attacker controlled server.
> > 
> > Simo.
> > 
> 
> SRVName in the certificate mitigates this security issue, if the
> client validates SRVName per RFC 6125.  But FreeIPA does not yet
> support issuing certs with SRVName.  I have an experimental branch
> but there are some issues to resolve.

Would be really cool to support indeed, as that definitely resolve
issues as long as the CA properly verifies ownership of the SRV Name
before granting it in certs.
Any thought on how we could support this with ACME ?
I guess we'd need an additional test ?

Simo.
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: [offlist] Re: Re: Modify LDAP/HTTP to add alternative names

[Simo Sorce via FreeIPA-users]

On Tue, 2020-09-29 at 09:44 -0400, Simo Sorce via FreeIPA-users wrote:
> On Tue, 2020-09-29 at 14:01 +0200, Christian Heimes via FreeIPA-users
> wrote:
> > On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
> > > On Thu, Sep 24, 2020 at 02:15:11PM -, Willie Lima via FreeIPA-users 
> > > wrote:
> > > > Hi guys,
> > > > 
> > > > I have 12 freeipa servers deployed with integrated DNS and CA
> > > > (realm and domain int.example.com).
> > > > 
> > > > I would like to make a DNS round-robin, for instance: request
> > > > ldap.int.example.com and forward for one of the servers and also
> > > > an external domain ldap.example.com
> > > > 
> > > > The problem is with the certificate, the TLS handshake fails
> > > > because there's no alternative name with ldap.int.example.com or
> > > > ldap.example.com.
> > > > 
> > > > I read the redhat documentation about certificate manipulation,
> > > > but I got very confused in fact how it works.
> > > > 
> > > > How can I do that? Are there another recommendation?
> > > > 
> > > Hello Willie,
> > > 
> > > It is not supported.  With some effort you could create the
> > > necessary objects and relationship in FreeIPA to permit issuance of
> > > such a certificate, then you could modify the certmonger tracking
> > > request (on every server) to request a certificate with those SANs.
> > > But the tracking request modifications would eventually be lost
> > > during ipa-server-upgrade (FreeIPA will see that the tracking
> > > request doesn't match expectations and replace it).
> > > 
> > > A possible alternative approach (I haven't tested it yet) is if you
> > > discover the LDAP servers via SRV records, i.e.
> > > _ldaps._tcp.int.example.com.  This would give "round robin"
> > > (actually service weighting but you get the idea) to all the LDAP
> > > servers in the topology.  I'd have to check if openldap client
> > > performs certificate validation properly in this scenario though.
> > 
> > OpenLDAP does not support SRV lookup. The python-ldap feature request
> > https://github.com/python-ldap/python-ldap/issues/178 contains more
> > information on the topic. I have recently implemented a new feature that
> > would allow you to implement SRV lookup more efficiently.
> > 
> > TLS hostname verification is not an issue. A client does not directly
> > use the SRV address. Instead you perform a SRV lookup which gives you a
> > list of hostnames with weights and priorities. An LDAP client connects
> > to the hostnames and uses the hostname to verify the identity of the
> > certificate.
> 
> This is cool but also problematic wrt security unless DNSSEC is used,
> as it is relatively easy to spoof a SRV record reply to point the
> client to an attacker controlled server.

So much for my evil plan to discuss this first off list :-D

Simo.

> Simo.
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] [offlist] Re: Re: Modify LDAP/HTTP to add alternative names

[Simo Sorce via FreeIPA-users]

On Tue, 2020-09-29 at 14:01 +0200, Christian Heimes via FreeIPA-users
wrote:
> On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
> > On Thu, Sep 24, 2020 at 02:15:11PM -, Willie Lima via FreeIPA-users 
> > wrote:
> > > Hi guys,
> > > 
> > > I have 12 freeipa servers deployed with integrated DNS and CA
> > > (realm and domain int.example.com).
> > > 
> > > I would like to make a DNS round-robin, for instance: request
> > > ldap.int.example.com and forward for one of the servers and also
> > > an external domain ldap.example.com
> > > 
> > > The problem is with the certificate, the TLS handshake fails
> > > because there's no alternative name with ldap.int.example.com or
> > > ldap.example.com.
> > > 
> > > I read the redhat documentation about certificate manipulation,
> > > but I got very confused in fact how it works.
> > > 
> > > How can I do that? Are there another recommendation?
> > > 
> > Hello Willie,
> > 
> > It is not supported.  With some effort you could create the
> > necessary objects and relationship in FreeIPA to permit issuance of
> > such a certificate, then you could modify the certmonger tracking
> > request (on every server) to request a certificate with those SANs.
> > But the tracking request modifications would eventually be lost
> > during ipa-server-upgrade (FreeIPA will see that the tracking
> > request doesn't match expectations and replace it).
> > 
> > A possible alternative approach (I haven't tested it yet) is if you
> > discover the LDAP servers via SRV records, i.e.
> > _ldaps._tcp.int.example.com.  This would give "round robin"
> > (actually service weighting but you get the idea) to all the LDAP
> > servers in the topology.  I'd have to check if openldap client
> > performs certificate validation properly in this scenario though.
> 
> OpenLDAP does not support SRV lookup. The python-ldap feature request
> https://github.com/python-ldap/python-ldap/issues/178 contains more
> information on the topic. I have recently implemented a new feature that
> would allow you to implement SRV lookup more efficiently.
> 
> TLS hostname verification is not an issue. A client does not directly
> use the SRV address. Instead you perform a SRV lookup which gives you a
> list of hostnames with weights and priorities. An LDAP client connects
> to the hostnames and uses the hostname to verify the identity of the
> certificate.

This is cool but also problematic wrt security unless DNSSEC is used,
as it is relatively easy to spoof a SRV record reply to point the
client to an attacker controlled server.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Delegation (S4U2Proxy) with apache's mod_auth_gssapi

[Simo Sorce via FreeIPA-users]

For interested parties (and archives) part of the issue was this:
https://github.com/gssapi/mod_auth_gssapi/issues/228

I am adding some logging to mod_auth_gssapi to make this kind of error
more readily discoverable from the apache error log.

Simo.

On Wed, 2020-09-02 at 13:00 +, Aurelien Bompard via FreeIPA-users
wrote:
> Hey folks! 
> 
> I have a Kerberos issue when using s4u2proxy with mod_auth_gssapi and IPA, 
> and I don't know where to look.
> 
> Basically, I've setup delegation in IPA (with servicedelegationrules and 
> targets) and in Apache's config for mod_auth_gssapi, but the directory where 
> the CCaches are supposed to be created remains empty (GssapiDelegCcacheDir).
> 
> In the apache log I only see:
>   GSS ERROR gss_acquire_cred[_from]() failed to get server creds: 
> [Unspecified GSS failure.  Minor code may provide more information ( SPNEGO 
> cannot find mechanisms to negotiate)]
> 
> For context, the webapp running in Apache is delegating for IPA's ldap 
> service, and if I contact it directly with ldapwhoami I get the right result, 
> so it's really the delegation I think.
> Also, the webapp is running in openshift, but that should not be a big issue 
> (besides for debugging) because I've already made it work elsewhere.
> 
> I have keytabs for the host and the HTTP service:
> 
> $ klist -k /etc/krb5.keytab 
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
>  
> --
>1 host/fasjson.stg.fedoraproject@stg.fedoraproject.org
>1 host/fasjson.stg.fedoraproject@stg.fedoraproject.org
> $ klist -k /etc/keytabs/http 
> Keytab name: FILE:/etc/keytabs/http
> KVNO Principal
>  
> --
>1 HTTP/fasjson.stg.fedoraproject@stg.fedoraproject.org
>1 HTTP/fasjson.stg.fedoraproject@stg.fedoraproject.org
> 
> And the section in Apache's config file is:
> 
>   AuthType GSSAPI
>   AuthName "Kerberos Login"
>   GssapiUseSessions On
>   Session On
>   SessionCookieName ipa_session path=/;httponly;secure;
>   SessionHeader IPASESSION
>   GssapiSessionKey file:/httpdir/run/session.key
>   GssapiCredStore keytab:/etc/keytabs/httpd
>   GssapiImpersonate On
>   GssapiDelegCcacheDir /httpdir/run/ccaches
>   GssapiDelegCcachePerms mode:0660
>   GssapiUseS4U2Proxy on
>   GssapiAllowedMech krb5
> 
> Here's what I'm seeing. When I'm authenticated with kerberos:
> $ klist
> Ticket cache: KEYRING:persistent:100029:100029
> Default principal: abomp...@stg.fedoraproject.org
> Valid starting ExpiresService principal
> 09/02/20 12:55:59  09/03/20 12:55:47  
> krbtgt/stg.fedoraproject@stg.fedoraproject.org
> 
> and I contact the web app with curl: curl --negotiate -u : 
> https://fasjson.stg.fedoraproject.org/v1/
> I get a 401 response with the log pasted above. The /httpdir/run/ccaches/ 
> directory remains empty, but I do get the service's entry in klist:
> $ klist
> Ticket cache: KEYRING:persistent:100029:100029
> Default principal: abomp...@stg.fedoraproject.org
> Valid starting ExpiresService principal
> 09/02/20 12:57:12  09/03/20 12:55:47  
> HTTP/fasjson.stg.fedoraproject@stg.fedoraproject.org
> 09/02/20 12:55:59  09/03/20 12:55:47  
> krbtgt/stg.fedoraproject@stg.fedoraproject.org
> 
> I don't know what I'm doing wrong and where I could dig. Could you point me 
> in the right direction? I'm also on IRC in the freeipa channel as abompard.
> 
> Thanks!
> 
> Aurélien
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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 Radius 5 seconds timeout

[Simo Sorce via FreeIPA-users]

On Mon, 2020-07-13 at 19:13 +, Sergiy Genyuk via FreeIPA-users
wrote:
> Radius server is DUO so when in FreeIPA  radius server set it sends 
> Access-Request to the DUO Radius server DUO check password against AD and 
> then push Accept message to the user mobile app... then returns  
> Access-Accept message back to FreeIPA.
> 
> Of cause it takes some time so I have setup timeout in Radius section in the 
> FreeIPA config but that's does not work. With any settings default timeout is 
> 5 seconds :-(
> 
> Now I am looking for help as my users not so happy with 5 sec timeout :-)   

FreeIPA's OTP support is not compatible with challenge response
mechanism that require user interaction like DUO.
The timeout is backed into too many layers.

I think DUO tokens can be configured to provide a OTP number in the app
directly before starting the authentication and w/o requiring
additional user confirmation, if this is an option you should use it.

IIRC,
I may be wrong, I'll let others correct me if that is the case.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: AddTrust CA expiration

[Simo Sorce via FreeIPA-users]

Hi Peter,
this is generally good info, and all the cleanups you mention below are
worth doing.

I just want to mention that if someone is in a pinch and needs to
prioritize operation that the only fixes that are really necessary are
those that involve certificate chains sent from servers to clients.

Namely the changes to the NSSDBs (steps 1 to 3, plus restart of
server's services to reread the new chains)

The changes to the certificate stores (like ca.crt or LDAP) (steps 4
and onwards) are definitely a good idea, but are not technically
necessary once the TLS servers send the right set of non-expired chains
to the clients.

So, definitely prioritize work on the servers, and leave clients last.

HTH,
Simo.

On Fri, 2020-06-05 at 18:34 +, Peter Lewis via FreeIPA-users wrote:
> I'm putting this out there to help others if they need it, but be wary as the 
> following caveats apply:
>   1. I am not an expert in FreeIPA.  Make a backup or snapshot if 
> possible.  For nssdb stuff, you can just tar up those directories for a 
> backup before munging the data in there.
>   2. I'm not 100% on order as I've been doing this repair over the last 
> few days.
>   3. There could be extra steps that are unnecessary
>   4. I'm on 4.6.5 so no cool new CA tools available
> 
> Here are my final steps that worked:
>   1. On all IPA servers, add new wildcard cert
>   ipa-server-certinstall -v -w -d certificate.key 
> certificate_bundle_with_servercert.pem
>   ipa-cacert-manage renew --external-cert-file 
> certificate_bundle_with_servercert.cer --external-cert-file locate_ca.pem 
> (I'm not sure this did anything)
>   
>   2. On all IPA servers, clean up all nss cache files by hand (as to not 
> delete the wrong cert)
>   a. list the contents
>   certutil -L -d 
>   /etc/httpd/alias
>   /etc/pki/pki-tomcat/alias
>   /etc/dirsrv/slapd-DOM-EXAMPLE-COM
>   /etc/ipa/nssdb
>   
>   b. Delete all but the *.lids and the DOM.EXAMPLE.COM and any 
> internal CA's like "Server-Cert cert-pki-ca"
>   certutil -D -d /etc/httpd/alias -n "CN=InCommon RSA 
> Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US"
>   certutil -D -d /etc/pki/pki-tomcat/alias -n 
> "CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey 
> City,ST=New Jersey,C=US"
>   etc
>   3. On all IPA servers, add in the 3 certs for the new path C chain.   
> They're named locally as c1, c2 and c3.pem locally.  Comodo, InCommon, 
> Usertrust (I scripted it to take $1 as the nssdb path) to each of the above 
> nssdb caches.
>   certutil -A -d $1 -i c1.pem -n "C=GB, ST=Greater Manchester, 
> L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services" -t "C,,"
>   certutil -A -d $1 -i c2.pem -n "C=US, ST=New Jersey, L=Jersey 
> City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority" -t 
> "C,,"
>   certutil -A -d $1 -i c3.pem -n "C=US, ST=MI, L=Ann Arbor, 
> O=Internet2, OU=InCommon, CN=InCommon RSA Server CA" -t "C,,"
>   4. On all IPA servers, update the /etc/ipa/ca.crt with the chain by hand
>   5. On all IPA servers, restart IPA client
>   a. ipasvc restart
>   6. On just one Server, now to remove the CA's from LDAP itself (it gets 
> replicated to the other 389ds servers).  
>   a. Get the DN names: 
>   ldapsearch -x -o ldif-wrap=no -b 
> dc=dom,dc=example,dc=com"(objectClass=ipaCertificate)" | grep dn:
>   b. Run the ldapdelete command on each (3 different CA's in my 
> case):
>   ldapdelete "cn=CN\3DInCommon RSA Server 
> CA\2COU\3DInCommon\2CO\3DInternet2\2CL\3DAnn 
> Arbor\2CST\3DMI\2CC\3DUS,cn=certificates,cn=ipa,cn=etc,dc=dom,dc=example,dc=com"
>  -D 'cn=directory manager' -W
>   7. On the same server as above, now to Add in the CA's again:
>   a. ipa-cacert-manage -v install 
> certificate_bundle_without_servercert.pem
>   8. On all IPA servers run:
>   a. kinit admin (or whatever admin account you're using)
>   b. ipa-certupdate
>   9. On all client's:
>   a. manually update /etc/ipa/ca.crt with the new chain + local 
> CA.  Same step as we did with #5 above
>   b. kinit admin
>   c. ipa-certupdate
>   
> Good luck.
>   
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> 

[Freeipa-users] Re: root CA 4096 bits signing key

[Simo Sorce via FreeIPA-users]

On Wed, 2020-06-03 at 14:58 +0200, Natxo Asenjo via FreeIPA-users
wrote:
> On Tue, Jun 2, 2020 at 8:33 PM Alexander Bokovoy 
> wrote:
> 
> > On ti, 02 kesä 2020, Natxo Asenjo via FreeIPA-users wrote:
> > > hi,
> > > 
> > > We have a new realm with rhel 7.8 and a default CA key of 2048 bits.
> > > 
> > > Recently a question arose to upgrade this to 4096 bits.
> > > 
> > > According to this blog post
> > > 
> > https://frasertweedale.github.io/blog-redhat/posts/2020-01-28-freeipa-override-ca-key-size.html
> > > ) this should already be possible for new deployments with RHEL 8.1 but is
> > > it possible to configure the root CA and eventually sub CAs to use the
> > 4096
> > > bits signing keys? In doing so, do we need to resign all certificates
> > > already in use?
> > > 
> > > Is it possible to do this in RHEL 7 or do we need to update the CA hosts
> > to
> > > 8.1 to achieve it?
> > 
> > Dogtag supports custom CA properties for the main CA and you can specify
> > them in a pki override file when deploying IPA. Not all properties
> > described in pki_default.cfg(5) make sense for FreeIPA CA deployment so
> > we limit them (you'll get an error for those in the override file) but
> > CA key size is configurable in 4.8.0+.
> > 
> > SubCA configuration is hardcoded in Dogtag's source code. They are
> > always RSA 2048. So there is no way to use 4096 bits signing keys for them.
> > 
> > In FreeIPA 4.8.0+ default CA signing key size is 3072. We found that it
> > is a good compromise for real world workloads. According to
> > https://www.keylength.com/, NIST 800-57 Part 1 Rev. 4 recommends 3072
> > bit RSA keys for keys that are used beyond 2030 for 128 bit strength.
> > 
> > 
> good to know, thanks!
> 
> Be aware that internal defaults in certmonger are set to RSA 2048 in
> > case explicit signing key algorithm and size are missing in the
> > certificate request.
> > 
> 
> we use getcert request -g 4096 and -G points currently to rsa so this seems
> ok.
> 
> ...
> Abusing this thread, is it possible to re-key the root CA with a with a
> longer key length while keeping the sub CAs and rest of signed certificates
> or do we need to reissue all certificates for everything?

In principle you can always create a new CA and then sign any other CA
including the original CA with its keys. I do not know if we make this
easy in FreeIPA though.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: where to place the freeipa server in a segmented network

[Simo Sorce via FreeIPA-users]

On Fri, 2020-05-08 at 10:27 +, Rob van Halteren via FreeIPA-users
wrote:
> Hello,
> 
> I have network consisting out a LAN,WLAN,DMZ and a PRODUCTION network, 
> separated by a firewall that performs the routing and connections to the 
> outside world.
> I want to introduce Identity management using a FreeIPA server for my 
> network. Most client machines will be on the LAN network, but not all.
> Most servers reside on the PRODUCTION network
> 
> I am trying to figure out where to place the FeeIPA server in this network. 
> I want to be able to authenticate all servers,client machines and also be 
> able to authenticate client machines that are connected via a VPN connection 
> that is hosted on the firewall.
> 
>  Sorry for having to ask this. I have been looking around on the net and this 
> list but found little help on this topic.
> Any advice would be welcome.

I placed my IdM server in the Lan, and then poked holes in the firewall.
In your case placing it in PRODUCTION would be just as fine, as long as all 
other networks can route to it.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Problems after replacing SSL certificates

[Simo Sorce via FreeIPA-users]

On Tue, 2020-04-21 at 12:25 +, Andreas Bulling via FreeIPA-users
wrote:
> The admin login problem I just managed to fix - missing trailing slash in a 
> permanent redirect from http to https in Apache.
> 
> But the ISSUE/NEEDED_PREAUTH messages I'd still like to figure out if these 
> are not normal.

They are perfectly normal if immediately followed by a pre-
authenticated request.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Kerberized NFS Home directories

[Simo Sorce via FreeIPA-users]

On Fri, 2020-01-17 at 09:35 -0700, Kristian Petersen via FreeIPA-users
wrote:
> Hey all,
> 
> I am trying to get kerberized NFS home directories working in Ubuntu 18.04
> with the mapping info coming from IPA.  I can get them to mount on login in
> a multi-user target (terminal only), but not a graphical one (using gdm for
> login).  The messages I am seeing in the syslog seem to indicate that it is
> having issues communicating with the server hosting the NFS share and times
> out.  That doesn't make sense though since it works to mount in the
> terminal like I would expect.

Is GDM trying to mount or walk the home directory *before* performing
authentication?
Or are you tying to manually mount/walk in the home in a terminal and
failing?

A failure indicates that the rpc.gssd daemon cannot find kerberos
credentials of the user.

What kind of credential cache do you use? Is it the same between
graphical and console logins? Do you use rpc.gssd integrated with gss-
proxy or standalone?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Troubles accessing kerberized website

[Simo Sorce via FreeIPA-users]

On Tue, 2020-01-14 at 15:59 +0100, Ronald Wimmer via FreeIPA-users
wrote:
> Some minutes ago and without changing anything servicea started working 
> again on my Linux client whereas the problem persists on the Linux 
> client of a colleague.

There isn't much to go on here, however I would look in two directions 
initially.
Check whether your client or the server are experiencing any clock
skew.
The max clock skew is 5 minutes, so if the clocks of the two systems
difference is close to 5 minutes, small variations in communication
time may affect access.
The other thing may be related to DNS/discovery issues, esp for people
roaming in and out of their "home" network, esp if the service in
question use a DNS name (and therefore SPN) that is not part of the
same AD Domain Name subdomain.
to debug what is going on you could restart your browser from a
terminal by first setting the KRB5_TRACE envrionment variable like so:
$ KRB5_TRACE=/tmp/krb5.trace.log firefox

Or similar (not, for Firefox, if you call this cmdline while the
browser is already open, the env var will not be set as firefox will
ask the existing process to open a new window and then will exit).

Once you have a trace you can see if there were any specific errors in
trying to get a ticket for the target server that give you a better
clue.

HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: LDAP connections to Active Directory not secure

[Simo Sorce via FreeIPA-users]

The port alone won't tell you anything, in AD communication happens on
port 389, but is then upgraded via SASL/GSSAPI to use a secure channel
(pretty much like you do with STARTTLS).

On Tue, 2019-12-17 at 21:56 +, Jones, Bob (rwj5d) wrote:
> Okay, I’ve narrowed it down to the sssd_be process that has a
> standard ldap connection to the AD servers (at least according to
> lsof -i).
> 
> — 
> Bob Jones
> Lead Linux Services Engineer
> ITS ECP - Linux Services
> 
> > On Dec 17, 2019, at 4:49 PM, Jones, Bob (rwj5d) via FreeIPA-users 
> >  wrote:
> > 
> > That’s good to know, however *something* is talking to Active Directory via 
> > LDAP in an insecure manner.  All that is running on these servers are 
> > things installed via yum install ipa-server.  Would sssd or 389 Directory 
> > Server be talking to Active Directory for some reason as the Active 
> > Directory admins are seeing binds from the IDM servers with binding type 0 
> > which means an unsigned bind.  They show 496 of those connections in the 
> > past 24 hours from our IPA servers.
> > 
> > — 
> > Bob Jones
> > Lead Linux Services Engineer
> > ITS ECP - Linux Services
> > 
> > > On Dec 17, 2019, at 4:11 PM, Simo Sorce  wrote:
> > > 
> > > On Tue, 2019-12-17 at 20:09 +, Jones, Bob (rwj5d) via FreeIPA-users 
> > > wrote:
> > > > Hello all,
> > > > 
> > > > Our Active Directory team is working on a project to get rid of all
> > > > insecure LDAP communications to Active Directory, and it seems our
> > > > FreeIPA servers are doing just that.  I did a quick search and didn’t
> > > > find anything definitive.  How do I go about ensuring that LDAP
> > > > queries from my FreeIPA servers are using TLS against the Active
> > > > Directory servers?
> > > 
> > > They won't, your servers use a different security channel called GSSAPI
> > > that is just as good, and is the same security mechanism Windows own
> > > clients use to talk to Active Directory. This should be sufficient.
> > > 
> > > HTH,
> > > Simo.
> > > 
> > > > Pertinent details:
> > > > 
> > > > Server is running on Red Hat Enterprise Linux Server release 7.7 
> > > > (Maipo) and is version:
> > > > 
> > > > ipa-server  4.6.5-11.el7_7.3
> > > > sssd1.16.4-21.el7
> > > > 389-ds-base 1.3.9.1-10.el7
> > > > 
> > > > — 
> > > > Bob Jones
> > > > Lead Linux Services Engineer
> > > > ITS ECP - Linux Services
> > > > 
> > > > ___
> > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives: 
> > > > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> > > 
> > > -- 
> > > Simo Sorce
> > > RHEL Crypto Team
> > > Red Hat, Inc
> > 
> > ___
> > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: LDAP connections to Active Directory not secure

[Simo Sorce via FreeIPA-users]

On Tue, 2019-12-17 at 20:09 +, Jones, Bob (rwj5d) via FreeIPA-users 
wrote:
> Hello all,
> 
> Our Active Directory team is working on a project to get rid of all
> insecure LDAP communications to Active Directory, and it seems our
> FreeIPA servers are doing just that.  I did a quick search and didn’t
> find anything definitive.  How do I go about ensuring that LDAP
> queries from my FreeIPA servers are using TLS against the Active
> Directory servers?

They won't, your servers use a different security channel called GSSAPI
that is just as good, and is the same security mechanism Windows own
clients use to talk to Active Directory. This should be sufficient.

HTH,
Simo.

> Pertinent details:
> 
> Server is running on Red Hat Enterprise Linux Server release 7.7 (Maipo) and 
> is version:
> 
> ipa-server4.6.5-11.el7_7.3
> sssd  1.16.4-21.el7
> 389-ds-base   1.3.9.1-10.el7
> 
> — 
> Bob Jones
> Lead Linux Services Engineer
> ITS ECP - Linux Services
> 
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: group management on freeipa clients

[Simo Sorce via FreeIPA-users]

I strongly recommend reading this article:
https://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-run-docker-in-centos-fedora-or-rhel/

And based on it, I would a) reconsider if using sudo is not a better
idea, b) recommend, if possible, to create the docker group locally and
add users explicitly on the specific machines.

I would fallback to a global docker group that basically gives root to
any user on any machine with docker installed they have access to only
as a least resort.

Simo.

On Wed, 2019-10-23 at 19:07 +, Jason Dunham via FreeIPA-users
wrote:
> Hi I'm trying to figure out the best practice for groups on my client servers.
> I have several computation workstation hosts that have been added as freeipa 
> clients, and several engineers who want to run docker on them
> Members of the 'docker' group (gid=999 on some machines, for example) can run 
> docker without needing sudo, which is what I want to roll out to all 
> machines.  Ideally this would be managed from freeipa with LDAP groups, and 
> so anyone in the 'engineers' group should also be a member of the 'docker' 
> group.
> 
> When I create a 'docker' group on freeIPA it will have some other gid and the 
> client sees that.
> Should I just delete the original docker group from my hosts and let it get 
> it from ldap, or should I go into /etc/group and change the gid to the one 
> that matches the right ldap gid, or preferably something easier than that?
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: is it possible to enable constrained delegation for only some users?

[Simo Sorce via FreeIPA-users]

On Tue, 2019-10-22 at 14:31 -0400, Simo Sorce via FreeIPA-users wrote:
> On Tue, 2019-10-22 at 18:43 +0300, Alexander Bokovoy via FreeIPA-users
> wrote:
> > On ti, 22 loka 2019, Charles Hedrick via FreeIPA-users wrote:
> > > ok. So delegation works. Now we come to the question of how to
> > > configure it in gssproxy. The man page describes the syntax of the file
> > > but not how it actually works. Any suggestions?
> > 
> > That is something for Simo, as gssproxy upstream. Unfortunately, I have
> > no time right now to investigate that.
> > 
> > May be you can file a ticket to gssproxy asking to document that?
> 
> What's the ask exactly ?

If it is NFS related please read this first:
https://pagure.io/gssproxy/blob/master/f/docs/NFS.md

> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: is it possible to enable constrained delegation for only some users?

[Simo Sorce via FreeIPA-users]

On Tue, 2019-10-22 at 18:43 +0300, Alexander Bokovoy via FreeIPA-users
wrote:
> On ti, 22 loka 2019, Charles Hedrick via FreeIPA-users wrote:
> > ok. So delegation works. Now we come to the question of how to
> > configure it in gssproxy. The man page describes the syntax of the file
> > but not how it actually works. Any suggestions?
> 
> That is something for Simo, as gssproxy upstream. Unfortunately, I have
> no time right now to investigate that.
> 
> May be you can file a ticket to gssproxy asking to document that?

What's the ask exactly ?

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: FreeIPA with multiple domains not mappings ids correctly on NFS

[Simo Sorce via FreeIPA-users]

Hi Kevin,
comments inline.

On Mon, 2019-10-07 at 11:50 -0500, Kevin Vasko wrote:
> Thanks.
> 
> So the clients have different host names depending on where they are located 
> geographically.
> 
> For example 
> 
> machines in CA have a FQDN of client1.ca.example.com
> 
> machines in NY have a FQDN of client8.ny.example.com
> 
> They both still belong to the same REALM of EXAMPLE.COM.

Good, REALM an domain should be the same in your case IMO.

Subdomains are just an organizational tool for you, the actual
authentication/identity domain is the same as the REALM.

> In their idmapd.conf file the 
> 
> # Domain = hostname.local
> 
> is commented out, and by default it uses the hostnames domain as the value.
> 
> So client1 Domain value by default would be set to ca.example.com and client8 
> would be set to ny.example.com.
> 
> Should I be listing both ca.example.com AND ny.example.com in their 
> idmapd.conf file? 

Don't think so

> Based off what you are saying I should just be able to get away with listing 
> “Domain = example.com” which is the REALM? 

Yes, this is what you should do, IMO.

Simo.

> 
> -Kevin
> 
> > On Oct 7, 2019, at 11:40 AM, Simo Sorce  wrote:
> > 
> > Note I assume that by "domains" you mean just DNS domains not separate
> > FreeIPA installs, if they are separate installs then it would be a lot
> > more complicated.
> > 
> > Another way that you can handle auth sys is to configure the domain on
> > the server (as any of the domain strings you want) and then use the
> > same domain on all clients), that should make them work.
> > 
> > > On Mon, 2019-10-07 at 12:37 -0400, Simo Sorce via FreeIPA-users wrote:
> > > If you use krb5 authentication you should have no issues, are you using
> > > auth=sys instead ?
> > > 
> > > > On Fri, 2019-10-04 at 17:10 -0500, Kevin Vasko via FreeIPA-users wrote:
> > > > Hello,
> > > > 
> > > > I’ve got FreeIPA setup where I have multiple domains for client 
> > > > machines depending on their geography.
> > > > 
> > > > For example, ca.example.com, and ny.example.com. 
> > > > 
> > > > I have a NFS server in nfs-server.ny.example.com and users mapping the 
> > > > NFS server on their clients from ny.example.com and ca.example.com. 
> > > > Users in ny.example.com show files owner:group just fine but users in 
> > > > ca.example.com everything on the nfs server shows nobody:nogroup or 
> > > > nobody: 4294967294
> > > > 
> > > > On the clients I’m seeing this issue on I see these error messages in 
> > > > the log.
> > > > 
> > > > Oct  4 16:53:14 aiml1 nfsidmap[7867]: nss_getpwnam: name 
> > > > ‘u...@ny.example.com' does not map into domain 'ca.example.com’
> > > > 
> > > > I did some googling and people are saying to add the domain to 
> > > > /etc/idmapd.conf but since I already have multiple domains (3 actually) 
> > > > I don’t see how this will work for all instances unless I can add 
> > > > multiple domains. I don’t see an obvious way to add multiple domains.
> > > > 
> > > > Is there a clean way to handle this?
> > > > 
> > > > -Kevin
> > > > ___
> > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives: 
> > > > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> > > 
> > > -- 
> > > Simo Sorce
> > > RHEL Crypto Team
> > > Red Hat, Inc
> > > 
> > > 
> > > 
> > > ___
> > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> > 
> > -- 
> > Simo Sorce
> > RHEL Crypto Team
> > Red Hat, Inc
> > 
> > 
> > 
> > 

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: FreeIPA with multiple domains not mappings ids correctly on NFS

[Simo Sorce via FreeIPA-users]

Note I assume that by "domains" you mean just DNS domains not separate
FreeIPA installs, if they are separate installs then it would be a lot
more complicated.

Another way that you can handle auth sys is to configure the domain on
the server (as any of the domain strings you want) and then use the
same domain on all clients), that should make them work.

On Mon, 2019-10-07 at 12:37 -0400, Simo Sorce via FreeIPA-users wrote:
> If you use krb5 authentication you should have no issues, are you using
> auth=sys instead ?
> 
> On Fri, 2019-10-04 at 17:10 -0500, Kevin Vasko via FreeIPA-users wrote:
> > Hello,
> >  
> > I’ve got FreeIPA setup where I have multiple domains for client machines 
> > depending on their geography.
> >  
> > For example, ca.example.com, and ny.example.com. 
> >  
> > I have a NFS server in nfs-server.ny.example.com and users mapping the NFS 
> > server on their clients from ny.example.com and ca.example.com. Users in 
> > ny.example.com show files owner:group just fine but users in ca.example.com 
> > everything on the nfs server shows nobody:nogroup or nobody: 4294967294
> >  
> > On the clients I’m seeing this issue on I see these error messages in the 
> > log.
> >  
> > Oct  4 16:53:14 aiml1 nfsidmap[7867]: nss_getpwnam: name 
> > ‘u...@ny.example.com' does not map into domain 'ca.example.com’
> >  
> > I did some googling and people are saying to add the domain to 
> > /etc/idmapd.conf but since I already have multiple domains (3 actually) I 
> > don’t see how this will work for all instances unless I can add multiple 
> > domains. I don’t see an obvious way to add multiple domains.
> >  
> > Is there a clean way to handle this?
> > 
> > -Kevin
> > ___
> > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: FreeIPA with multiple domains not mappings ids correctly on NFS

[Simo Sorce via FreeIPA-users]

If you use krb5 authentication you should have no issues, are you using
auth=sys instead ?

On Fri, 2019-10-04 at 17:10 -0500, Kevin Vasko via FreeIPA-users wrote:
> Hello,
>  
> I’ve got FreeIPA setup where I have multiple domains for client machines 
> depending on their geography.
>  
> For example, ca.example.com, and ny.example.com. 
>  
> I have a NFS server in nfs-server.ny.example.com and users mapping the NFS 
> server on their clients from ny.example.com and ca.example.com. Users in 
> ny.example.com show files owner:group just fine but users in ca.example.com 
> everything on the nfs server shows nobody:nogroup or nobody: 4294967294
>  
> On the clients I’m seeing this issue on I see these error messages in the log.
>  
> Oct  4 16:53:14 aiml1 nfsidmap[7867]: nss_getpwnam: name 
> ‘u...@ny.example.com' does not map into domain 'ca.example.com’
>  
> I did some googling and people are saying to add the domain to 
> /etc/idmapd.conf but since I already have multiple domains (3 actually) I 
> don’t see how this will work for all instances unless I can add multiple 
> domains. I don’t see an obvious way to add multiple domains.
>  
> Is there a clean way to handle this?
> 
> -Kevin
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: HBAC: Negate?

[Simo Sorce via FreeIPA-users]

On Mon, 2019-07-29 at 11:47 -0400, Simo Sorce via FreeIPA-users wrote:
> Christina,

apologies for the typo, I meant "Christian" of course.

> the easiest way to handle your situation is to create a new group for
> allowed hosts, add all current hosts then remove the 10 you care about.
> Finally set up an auto-membership rule so all new hosts are
> automatically added to that group.
> 
> You will have to monitor/remove any new "special" server you may add,
> but this will work to obtain your "negate" rule in an easily
> maintainable way.
> 
> HTH,
> Simo.
> 
> On Mon, 2019-07-29 at 11:31 -0400, Rob Crittenden via FreeIPA-users
> wrote:
> > Christian Reiss via FreeIPA-users wrote:
> > > Hey,
> > > 
> > > I take it this is not possible an no one does this?
> > 
> > It is not possible. HBAC only provides allow rules.
> > 
> > rob
> > 
> > > 
> > > -Chris.
> > > 
> > > On 26/07/2019 17:00, Christian Reiss via FreeIPA-users wrote:
> > > > Hey folks,
> > > > 
> > > > We are running a lot of server, we nearly exhausted and allocated our
> > > > /29 ipv6 allocation*.
> > > > 
> > > > Let's say we have 10 really, really important servers that only a
> > > > handful of people should be able to access. Everyone else not.
> > > > 
> > > > So I have a fixed group of known "critical servers" and a dynamic, ever
> > > > changing group of "the rest". As I have not yet found a "negate" option
> > > > what is the smartest way to allow a fixed group to a fixed set of
> > > > servers, while everyone else has access to everything else but this?
> > > > 
> > > > 
> > > > Thanks and have a great weekend folks!
> > > > -Chris.
> > > > 
> > > > * Alternate facts disclaimer: The given number has been optimized to
> > > > impress, bedazzle and to intimidate. The real number of host might be
> > > > substantially smaller.
> > > > 
> > > > 
> > > > ___
> > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: HBAC: Negate?

[Simo Sorce via FreeIPA-users]

Christina,
the easiest way to handle your situation is to create a new group for
allowed hosts, add all current hosts then remove the 10 you care about.
Finally set up an auto-membership rule so all new hosts are
automatically added to that group.

You will have to monitor/remove any new "special" server you may add,
but this will work to obtain your "negate" rule in an easily
maintainable way.

HTH,
Simo.

On Mon, 2019-07-29 at 11:31 -0400, Rob Crittenden via FreeIPA-users
wrote:
> Christian Reiss via FreeIPA-users wrote:
> > Hey,
> > 
> > I take it this is not possible an no one does this?
> 
> It is not possible. HBAC only provides allow rules.
> 
> rob
> 
> > 
> > -Chris.
> > 
> > On 26/07/2019 17:00, Christian Reiss via FreeIPA-users wrote:
> > > Hey folks,
> > > 
> > > We are running a lot of server, we nearly exhausted and allocated our
> > > /29 ipv6 allocation*.
> > > 
> > > Let's say we have 10 really, really important servers that only a
> > > handful of people should be able to access. Everyone else not.
> > > 
> > > So I have a fixed group of known "critical servers" and a dynamic, ever
> > > changing group of "the rest". As I have not yet found a "negate" option
> > > what is the smartest way to allow a fixed group to a fixed set of
> > > servers, while everyone else has access to everything else but this?
> > > 
> > > 
> > > Thanks and have a great weekend folks!
> > > -Chris.
> > > 
> > > * Alternate facts disclaimer: The given number has been optimized to
> > > impress, bedazzle and to intimidate. The real number of host might be
> > > substantially smaller.
> > > 
> > > 
> > > ___
> > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: trust AD - kerberos - how it works?

[Simo Sorce via FreeIPA-users]

On Thu, 2019-07-11 at 12:09 +0100, lejeczek via FreeIPA-users wrote:
> hi guys
> 
> I've been having my IPA deployment trusting AD for a while now and it's
> been behaving pretty good I must say, except for one thing - kerberos,
> in some places at least.
> 
> What I've needed really, or mainly that trust for, was ssh with gssapi
> and that is what I'd like to ask about - interaction between IPA and AD
> when it comes to kerberos - my AD win-clients sometimes would have
> tickets and be able to ssh with gssapi, some other time it would not
> work and ssh would ask for passwords.
> 
> I cannot really spot any pattern there and I hope some expert could
> decipher this for me and help to understand what and why that happens.
> 
> many thanks, L.

Generally there are two main cases:

1) your IPA host lives in a domain that is actually owned by AD, AD
will never return a cross-realm ticket and direct their clients to the
IPA KDC for domains it owns, so the clients will get back an error when
trying to obtain a ticket for those hosts and fall back to password
authntication.

2) You are using a non-qualified hostname or an alias (CNAME) that is
not registered in the IPA KDC as an alias for the host you want to
reach. This causes the client to be unable to obtain a ticket for the
target machine falling back to password authentication.

Additional DNS resolution failure may cause these issues too.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
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: Simple help with User Groups

[Simo Sorce via FreeIPA-users]

On Fri, 2019-05-17 at 14:19 +, SOLER SANGUESA Miguel via FreeIPA-
users wrote:
> Hello,
> 
> I don't think it is a good idea to create a IPA posix group with the
> same GID. I think the best option is adding the IPA user to the local
> group as you tried to do. The only problem is that you used the short
> username, and you need to use username@domain. Something like this:
> # groupmems -g admins -a ri...@ipa.domain.com


You need to use the same name that is being use by the system.
If a fully qualified name is being used then yes the fqdn needs
to be in the group file, if shortnames are configured then the
short name needs to be used.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

___
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: Simple help with User Groups

[Simo Sorce via FreeIPA-users]

On Thu, 2019-05-16 at 22:30 +, Jim Rice via FreeIPA-users wrote:
> I have a host (lucee) and a user (ricky).
> I want to allow ricky to modify files on lucee owned by a group (admins).
> 
> How is this accomplished using the freeIPA server?

You create a POSIX group on the FreeIPA server and assign the user to
it.

> I tried adding the host, and the user, then created a user group and added 
> the user to it.
> The user group was added to the host.

Hosts are irrelevant for user groups.

> The user is able to login to the host, but is not able to modify group owned 
> files,
> and the group admins does not show up in his id ...
> [lucee]$ id
> uid=15864(ricky) gid=15864(ricky) 
> groups=15864(ricky),15865(devops) 
> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

did you log out and then log in again?
Group memberships are set on the parent process (shell) at login time
and never changed for the duration of a session.

> There is an entry in the local /etc/group file:
> admins:x:2000:ricky
> 
> Is this the wrong approach?

You "can" use a local group, but if you want the same group on all
hosts then you should create such group on the server.
If you do want the group only on that host then you do not need to
create anything on the IPA server. You still need to logout and login
again whenever you change anything about the user or the groups.

> When the User Group is being added, there is a Group Type selection.
> What is the difference between Non-POSIX, External, and POSIX?

Non-posix is just an organizational group in FreeIPA, it won't show up
as a group on hosts. You can use it for HBAC rules for example so that
you do not pollute the hosts with groups that never are used for file
ownership.

External groups are special glue groups used to get users from trusted
AD domains into IPA groups.

Posix groups are the groups used to grant file access on hosts, as they
have a GID number.

> Would I need to set the GID to 2000 in freeIPA, or something else?

If you have pre-existing files and do not want to chgrp to change the
GID everywhere then yes you would do that, assuming you want the group
to be domain wide as mentioned above.

> (Actually, is you select External, the GID becomes grayed out.)

See above.

> I can't seem to find any documentation on how to set this up.
> admins:x:2000:luceeuser,rick


https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/identity_management_guide/user-groups

HTH,
Simo.


-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

___
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: TOTP generators producing different values

[Simo Sorce via FreeIPA-users]

On Tue, 2018-12-04 at 09:43 +0100, Florence Blanc-Renaud via FreeIPA-
users wrote:
> On 12/3/18 6:10 PM, Brian Topping via FreeIPA-users wrote:
> > Hi all, I have a question about TOTP authenticators (Google Authenticator, 
> > Authy, FreeOTP):
> > 
> > Why is it that a given URL/QRCode can load into all three authenticators, 
> > but all three give different OTP values at any given time and only FreeOTP 
> > actually works?
> 
> Hi,
> 
> TOTP values are generated using the current time to ensure their 
> uniqueness. I didn't have any issue when using Google Authenticator and 
> FreeOTP, but you need to make sure that the clocks are in sync when 
> using TOTP.

Keep in mind that a hardware (or even software) token may have clock
drifting issues. These are handled by the server via token re-sync.
It is best to have clocks in sync, but if the clock doesn't jump wildly
the server should be able to handle clock differences with, at most, a
re-sync.

Simo.

> > 
> > When I run `ipa otp-sync` with values from Authy, it crashes:
> > 
> > ```
> > [root@ns-0 /]# ipa otptoken-sync 752f744e-1879-4499-a9c5-8932f739d26a
> > User ID: player1
> > Password:
> > First Code:
> > Second Code:
> > ipa: ERROR: non-public: AttributeError: 'NoneType' object has no attribute 
> > 'name'
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 139, in 
> > execute
> > result = self.Command[_name](*args, **options)
> >   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in 
> > __call__
> > return self.__do_call(*args, **options)
> >   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 475, in 
> > __do_call
> > ret = self.run(*args, **options)
> >   File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1199, in 
> > run
> > return self.forward(*args, **options)
> >   File "/usr/lib/python2.7/site-packages/ipaclient/plugins/otptoken.py", 
> > line 168, in forward
> > query['token'] = DN((obj.primary_key.name, args[0]),
> > AttributeError: 'NoneType' object has no attribute 'name'
> > ipa: ERROR: an internal error has occurred
> > ```
> > 
> 
> I could consistently reproduce the AttributeError exception. Could you 
> please open a ticket on pagure for this issue 
> (https://pagure.io/freeipa/new_issue)?
> 
> flo
> 
> 
> > Thanks kindly for any leads on this!
> > 
> > Brian
> > ___
> > 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

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

___
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: sftp file broswer causes 4 (System Error)

[Simo Sorce via FreeIPA-users]

On Tue, 2018-09-11 at 14:10 +1200, Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
> 
>  
> 
> We just had a bit of fuss involved user logins. We're using sssd 1.16.1 on a
> client and FreeIPA 4.5.4 (ok, it's really RHIdM)
> 
>  
> 
> We had a lot of users having issues logging and/or resetting their passwords
> on a host with 2FA enabled, and it turns out when they're using an advanced
> SSH client (e.g. MobaXterm) that also starts a SFTP session they can't login
> and we see error like:
> 
>  
> 
> Sep 11 00:09:05 lander sshd[27408]: pam_sss(sshd:auth): received for user
> testuser: 4 (System error)
> 
> Sep 11 00:09:06 lander sshd[27380]: error: PAM: Authentication failure for
> testuser from remote.local
> 
>  
> 
> If the SFTP file browser is disabled, or it's protocol is set to use SCP
> then logins progress normally.
> 
>  
> 
> In FreeIPA we've enabled 2FA on a per-host basis and the HBAC rule only
> allows sshd services, so if these were the cause of the '4 (System error)'
> failures then it'd be much better if the error reports were more meaningful.
> 
>  
> 
> Does anyone have any advice on setting up SFTP so that it works (and
> ideally, doesn't need repeated entry of credentials).

You should find out if your client supports using a master connection
for SSH, instead of trying to open multiple different connection for
SSH and SFTP. In the end it is a client issue if it can't properly
prompt for credentials when it uses multiple different authenticated
connections (I assume this client is caching passwords and trying to
resubmit old 2FA codes in the process ? [Caching of password seem
already bad in itself if that's the case, how long does it hold onto
your creds? will it leak them?])

HTH,
Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
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: Can't ssh using GSSAPI delegation from one freeipa client to another consistently

[Simo Sorce via FreeIPA-users]

On Fri, 2018-09-07 at 11:49 -0400, Ranbir via FreeIPA-users wrote:
> On Thu, 2018-09-06 at 16:24 -0400, Simo Sorce via FreeIPA-users wrote:
> > I need to ask, if you really mean "delegation" or if you mean
> > "single-
> > sign-on" here.
> 
> I definitely am. I've been using the -K switch for ssh to ensure GSSAPI
> credentials are used and forwarded.
> 
> > Delegation is completely unrelated to whatever server name is used,
> > so
> > a short name won't break delegation per se. However SSO will be
> > broken
> > if a ticket cannot be found.
> 
> I've also been double checking that I have a ticket each time I've
> tested.

So you are able to SSH into the other server without any password
prompt, but when you klist there your ccache is empty, is this what you
are experiencing ?

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
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: Can't ssh using GSSAPI delegation from one freeipa client to another consistently

[Simo Sorce via FreeIPA-users]

On Thu, 2018-09-06 at 16:03 -0400, Ranbir via FreeIPA-users wrote:
> On Thu, 2018-09-06 at 19:25 +0300, Alexander Bokovoy via FreeIPA-users
> wrote:
> > 
> > By default FreeIPA deals with fully qualified host names. Unless you
> > added non-FQDN names as aliases to your host records in IPA (I
> > suspect
> > you don't), doing non-FQDN ssh access will not work if they aren't
> > resolved by the ssh client to FQDN ones like others in the thread
> > pointed out.
> 
> I still don't understand how resolving to the FQDN works from some
> hosts and not others. For one, the DNS config on all servers is the
> same. Second, the hosts file for each follows the same format. Third, I
> don't have any aliases in IPA.

I need to ask, if you really mean "delegation" or if you mean "single-
sign-on" here.

Delegation is completely unrelated to whatever server name is used, so
a short name won't break delegation per se. However SSO will be broken
if a ticket cannot be found.

Simo.

--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
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: Can't ssh using GSSAPI delegation from one freeipa client to another consistently

[Simo Sorce via FreeIPA-users]

On Wed, 2018-09-05 at 16:19 -0400, Ranbir via FreeIPA-users wrote:
> Hello,
> 
> I have a Fedora 26 desktop joined to a freeipa domain running two ipa
> 4.5.4-10 servers on CentOS 7.5.1804. I have an odd "problem" I hope
> someone here can help me fix.
> 
> I can ssh from my desktop to any server in the domain using my password
> (i.e. interactive) or GSSAPI. Once on a server, I can ssh to some hosts
> in the domain using GSSAPI delegation, but not to others.
> 
> When GSSAPI delegation doesn't work, I see this error:
> 
> debug1: Unspecified GSS failure.  Minor code may provide more information
> Server host/ip...@theinside.rnr not found in Kerberos database

Is this the actual error? no editing ?

> I think I solved this once before, but it was a very, very long time
> ago and I don't have any notes to refer to. 
> 
> What am I messing up?

if ipa01 is really unqualified as you show up here that probably means
that you are either ssh-ing using the short name instead of the fully
qualified name, or you have reverse resolution enabled and a line in
your hosts file with "IP shortname longname", and the shortname is
resolved as the name of the server.


HTH,
Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
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: Hiding User Groups from WebUI

[Simo Sorce via FreeIPA-users]

On Wed, 2018-09-05 at 14:32 -0400, Rob Crittenden via FreeIPA-users
wrote:
> Heather A. Selbe via FreeIPA-users wrote:
> > This is going to be a strange one. I have a new instance of IPA I am
> > standing up, and did an migrate of users and groups from a prior IPA
> > instance. In the old instance, all of the user private groups were
> > hidden in the WebUI, but do still exist in the server, since I can find
> > them with ipa group_show and group_find. I've done some digging, but I'm
> > still unsure how to replicate this behavior on the new IPA master. The
> > new IPA is on 4.5.4-10 for reference. Any help will be appreciated.
> 
> Migration does not currently create user-private groups.
> 
> The reasoning is that it was computationally heavy to check the group
> for every user to see if there are any exceptions in which case either
> the migration would be perhaps aborted, or an override, something.
> 
> We have an RFE to add this capability, along with a number of other
> enhancements for migration, it just hasn't been put onto the roadmap yet.

A clarification that may not be evident from Rob's reply.
What he implied is that migration moves "user-private groups" in the
new instance as regular groups. This is why you see them in the UI.
Unfortunately there is no "blessed" method to turn a regular group into
a user-private group ...

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
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: Jira and Confluence user authentication with FreeIPA

[Simo Sorce via FreeIPA-users]

You can use something like KeyCloak or Ipsilon as an Idp to which you
auth via kerberos, and then use their SAML or OIDC tokens to auth to
Atlassian products.

The net effect is Single Sign On, it works without issues.

On Wed, 2018-08-29 at 10:22 -0500, Jacob Block via FreeIPA-users wrote:
> Thanks for sharing this. As a follow-up, is there currently a path
> for SSO with Jira + Confluence + Crucible and FreeIPA? It seems like
> there is a shortcoming of Atlassian products missing Kerberos
> support.
> 
> On Tue, Aug 28, 2018 at 4:14 PM Jacob Jenner Rasmussen via FreeIPA-users 
>  wrote:
> > I have just setup my Jira and Confluence instances to use my FreeIPA 
> > instance as their user directory. I'm leaving this message on how I did it 
> > in the hope somebody else find it useful.
> > 
> > Note: I did this with Confluence version 6.10.1 and Jira version 7.12.0
> > 
> > For confluence you should create the groups "confluence-administrators" and 
> > "confluence-users", and for Jira you should create the groups 
> > "jira-software-administrators" and "jira-software-users"
> > 
> > Please note that only users that are part of confluence-users or 
> > jira-software-users will be recognized by Confluence and Jira respectively. 
> > If you wan't a different set of users to appear in Confluence and Jira 
> > change the User Object Filter field appropriately.
> > 
> > Add a new LDAP user directory and configure as follows. This applied to 
> > both Confluence and Jira:
> > 
> > Server Settings:
> >  - Namel: FreeIPA
> >  - Directory Type: OpenLDAP
> >  - Server: example.com
> >  - Port: 389
> >  - Use SLL: false # Believe that you gonna to add the FreeIPA CA to the jdk 
> > cert store in order to enable this
> >  - Username: uid=admin,cn=users,cn=accounts,dc=example,dc=com# change 
> > admin to a service specfic account
> >  - Password: 
> > 
> > LDAP Schema:
> >  - Base DN: dc=example,dc=com
> >  - Additional User DN: cn=users,cn=accounts
> >  - Additional Group DN: cn=groups,cn=accounts
> > 
> > LDAP Permissions: Read Only
> > 
> > Advanced Settings: 
> > 
> > User Schema Settings:
> >  - User Object Class: inetorgperson
> >  - User Object Filter:
> >- for confluence: 
> > (&(objectclass=inetorgperson)(memberOf=cn=confluence-users,cn=groups,cn=accounts,dc=example,dc=com))
> >- for jira: 
> > (&(objectclass=inetorgperson)(memberOf=cn=jira-software-users,cn=groups,cn=accounts,dc=example,dc=com))
> >  - User Name Attribute: uid
> >  - User Name RDN Attribute: uid
> >  - User First Name Attriute: givenName  # This is wrong, FreeIPA doesn't 
> > seem to have anything fits this field
> >  - User Last Name Attribute: sn
> >  - User Display Name Attribute: displayName
> >  - User Email Attribute: mail
> >  - User Password Attribute: userPassword
> >  - User Password Encryption: SHA
> >  - User Unique ID Attribute: ipaUniqueID
> > 
> > Group Schema Settings:
> >  - Group Object Class: groupofnames
> >  - Group Object Filter: (objectclass=groupofnames)
> > Note: "groupofnames" should be all lowercase
> >  - Group Name Attribute: cn
> >  - Group Description Attribute: description
> > 
> > Membership Schema Settings:
> >  - Group Members Attribute: member
> >  - User Membership Attribute: memberOf
> >  - Use the User Membership Attribute: false   # I'm not sure what to set 
> > this to, but this works
> > 
> > 
> > One thing I haven't looked into that might be relevant to set under 
> > Advanced Settings is the Enabled Nested Groups setting.
> > ___
> > 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 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: Apache HTTPD Service Account Override

[Simo Sorce via FreeIPA-users]

On Thu, 2018-07-12 at 12:02 +, Ryan Slominski via FreeIPA-users
wrote:
> Further investigation suggests this might have something to do with
> gssproxy.   I was expecting to find the HTTP keytab at
> /etc/httpd/conf/ipa.keytab, but now see it is in
> /var/lib/ipa/gssproxy.  This problem only occurs if the PHP script is
> executed by the apache user in the context of the HTTPD web
> server.  Executing the PHP script directly such as "sudo -u apache
> php test.php" works as expected (the myservice principal is used).
> Anyone know why apache user in HTTPD context goes with  HTTP service
> principal despite the script executing kinit with a different
> principal and setting environment variables to try to use the
> alternative principal?

You really shouldn't kinit as the Apache user on an IPA system, unless
you fork/exec and explicitly set KRB5CCNAME so it does not conflict
(and overwrites) the ccaches used by Apache.

In that case you may also want to disable the GSS_USE_PROXY env var in
your subprocess so that gssproxy is not invoked at all.

But in general, do not mess with kerberos and the apache user on an IPA
server is the takeaway.

Simo.
___
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.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IRSW5NI6HZYA2XIXDXGGI2HPGGTJZGY6/

[Freeipa-users] Re: Problem with upgrade

[Simo Sorce via FreeIPA-users]

On Tue, 2018-06-12 at 12:15 -0700, Alessandro Perucchi via FreeIPA-
users wrote:
> Hello everyone,
> 
> We were using Freeipa on Fedora 24. And we are in the process to upgrade to
> Fedora 28.
> We have a cluster of 2 nodes (freeipa-01 and freeipa-02).
> 
> I am trying to upgrade one server after the other, from one release to the
> next.
> 
> Basically:
> 
> freeipa-01 Fedora 24 -> Fedora 25
> 
> freeipa-02 Fedora 24 -> Fedora 25
> freeipa-02 Fedora 25 -> Fedora 26
> 
> freeipa-01 Fedora 25 -> Fedora 26
> freeipa-01 Fedora 26 -> Fedora 27
> 
> freeipa-02 Fedora 26 -> Fedora 27
> freeipa-02 Fedora 27 -> Fedora 28
> 
> freeipa-01 Fedora 27 -> Fedora 28
> 
> Since Fedora doesn’t support to jump from one version to another, except
> one release at the time.
> 
> My idea is to check that once a server is upgraded, then everything is
> stable, before going to the next server, and try to be as near as possible
> from a version point of view between the 2 freeipa node cluster.
> 
> Today , I could
> upgrade without problems from Fedora 24 -> Fedora 25 on both nodes
> (freeipa-01 and freeipa-02).
> 
> In trying to upgrade to Fedora 26, I got some problems, the main problem is
> that the upgrade of ldap 389 is not successful, and the one from IPA either.
> After investigating a long moment, I have found that ns-slapd listen only
> to IPv6, on UDP, and NOT on IPv4 and TCP.
> 
> Here is what I have:
> 
> [root@freeipa-02 lib]# lsof -Pni |grep slap
> ns-slapd  21005dirsrv9u  IPv6 1617283379   0t0
>  UDP *:389
> ns-slapd  21005dirsrv   77u  IPv4 1617321218   0t0
>  TCP 10.100.0.102:60646->10.100.0.101:389 (ESTABLISHED)
> ns-slapd  21005dirsrv   81u  IPv4 1617317640   0t0
>  TCP 10.100.0.102:60648->10.100.0.101:389 (ESTABLISHED)
> 
> 
> So, I decided to look at the file dse.ldif, and found that the entry
> "nsslapd-port” was set to “0” and no “nsslapd-listenhost” was not set at
> all.
> I have then added the line
> 
> nsslapd-listenhost: 0.0.0.0
> 
> and changed the nsslapd-port to look like:
> 
> nsslap-port: 389
> 
> And after doing a
> 
> systemctl stop dirsrv@DOM-LOCAL ; systemctl start dirsrv@DOM-LOCAL
> 
> No changes… all modification on my dse.ldif were gone.
> 
> I stopped again the dirsrv, did again my changes on dse.ldif, and run the
> following command:
> 
> /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-DOM-LOCAL -i
> /var/run/dirsrv/slapd-DOM-LOCAL.pid
> 
> and now, I have the following:
> 
> [root@freeipa-02 updates]# lsof -Pni |grep 389
> ns-slapd  78507dirsrv   10u  IPv6 1681165214   0t0
>  UDP *:389
> ns-slapd  78507dirsrv   11u  IPv4 1681165216   0t0
>  TCP *:389 (LISTEN)
> ns-slapd  78507dirsrv  114u  IPv4 1684131928   0t0
>  TCP 10.100.0.102:389->10.100.0.110:36828 (ESTABLISHED)
> 
> So my questions are:
> - how to change the dse.ldif file?

You have to stop ns-slapd before changing the file.

> - Is there another way to ensure that the port that listen is TCP / 389 on
> IPv4?

The port was disabled during some upgrade operations, your situation
meant some upgrade failed and that old version failed to set back the
port in dse.ldif
This is a bug and shouldn't happen in recent versions.

> - Is there something that needs to be done between Fedora 25 and 26?

Is this upgrade bug repeatable ? (keep in mind that F26 is practically
EOL)

> Knowing that I will go to Fedora 28, is there something that I need to be
> aware of?

Yes, read this list archives before you attempt F28 upgrades, you may
have to use updates-testing as the GA bits where busted wrt replication
for upgrades.

> - Anything that can help me generally with my upgrade path?

In general your approach is ok, make backups :-)

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
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.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/R2OS5JMF6APWVNQZ3STCG7JGR7RRQB6O/

[Freeipa-users] Re: obtaining initial ticket via keytab

[Simo Sorce via FreeIPA-users]

On Mon, 2018-05-14 at 14:44 -0400, Josh via FreeIPA-users wrote:
> On 05/14/2018 01:29 PM, Alexander Bokovoy wrote:
> > Talking with Simo, we realized that since we are using random salt for
> > all IPA principals, you need to know the salt when creating a keytab
> > entry. You only can retrieve that via KRB5_TRACE for kinit like I did in
> > https://paste.fedoraproject.org/paste/KPt2PbYsdluhAJcVLdQjBg but since
> > salt is random, it may have characters that aren't clean for a shell
> > use, so your scripting mileage may vary. 
> 
> Thanks a lot! That is helpful. However man page for ktutil has no word 
> for salt:
> 
> add_entry
>    add_entry {-key|-password} -p principal -k kvno -e enctype
> 
> and attempt to add -s option results in invalid usage error.
> 
> usage: addent (-key | -password) -p principal -k kvno -e enctype
> 
> $ rpm -qf /usr/bin/ktutil
> krb5-workstation-1.15.1-8.el7.x86_64

I think -s has been added in 1.16 :-(

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: HBAC and Kerberos.

[Simo Sorce via FreeIPA-users]

On Thu, 2018-04-26 at 21:02 -0400, Rob Crittenden via FreeIPA-users
wrote:
> Ildefonso Camargo via FreeIPA-users wrote:
> > Hello,
> > 
> > At this point I am mostly looking for confirmation/denial of the
> > following observed behavior:
> > 
> > FreeIPA Kerberos will issue service tickets to a user with a valid TGT
> > regardless of access control rules (HBAC).
> > 
> > Procedure to observe:
> > 
> > 1. Create a test user.
> > 2. Allow that user to login to one host, and just one (via ssh or so),
> > HBAC is used.
> > 3. Check that the user has a TGT (klist),or issue kinit as needed.
> > 4. Try to ssh (or connect to any other Kerberos service) to any other
> > server, you will probably get access denied (PAM-based services) because
> > of HBAC, or even allowed (Kerberos-based services that do not use PAM).
> > 5. Get that ticket list again: you got service ticket for every single
> > host, even the ones to which you do not have access.
> > 
> > This is causing me great grieving ( :( ), because I was hoping to
> > control authorization to a Kerberos service using FreeIPA, it turns out
> > it just allows everyone in and now I have to add authorization at the
> > service level, which could eventually use PAM, but... come on, why
> > doesn't FreeIPA inspect access policies before issuing the ticket?
> > (unless it does and I am missing something?)
> 
> HBAC enforcement is done per host, on the pam level by service name. So
> if a service does not use PAM then HBAC does not apply.
> 
> > So... can you confirm if what I found is the way it is supposed to work
> > in its current state? (version 4.5.0)
> 
> Yes it is working as designed.

Let me add a point here that may escape the casual viewer.
Using PAM does not mean "authenticate via PAM", it means that the
software needs to run the PAM *account* stack to check if the user is
allowed to log in.
So you can safely use krb auth and still use HBAC rules provided the
software has switches to check the PAM account stack.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: dumb question - how many AD trust setup interactions are needed for multi-node replicating IPA cluster

[Simo Sorce via FreeIPA-users]

On Wed, 2018-04-11 at 14:36 -0400, Chris Dagdigian via FreeIPA-users
wrote:
> Hi folks,
> 
> Multi-region AWS IPA user here. We've got an ancient and brittle IPA 
> setup with broken replication and an inability to upgrade. Rather than 
> fix I want to stand up a whole new set of IPA servers running the latest 
> version so I can get replication working again as well as leverage all 
> the great new features in IPA and SSSD subsystem.
> 
> However in my environment it's an incredibly complex process to set up a 
> 1-way trust with Active Directory.
> 
> The administrators work for a managed service provider and they are 
> outside of the normal support loop so they rarely interact with peons 
> and outsiders like myself. Just getting their attention is a procedural 
> and political effort.  The first AD trust took more than 3 months to 
> setup (!)
> 
> 
> I need to start the process again for requesting a new AD trust 
> arrangement for the new IPA servers I intend to build.
> 
> Realized that I had a really dumb question ...
> 
> If my goal is to have a 4-node replicating cluster (2x in us-east AWS 
> region and 2x in eu-central-2 region) how many discrete AD trusts do I 
> actually have to arrange with my remote AD administrators?
> 
> If I get a good 1-way trust working on a single IPA node in the cluster, 
> will the replicating targets inherit this trust?
> 
> Do I need to set up the trust individually on each of the 4 planned IPA 
> boxes?

Hi Chris,
not a stupid question.

A Trust is a domain level property, when you establish a trust your whole IPA
domain is in a trust relationship with the AD domain.

Not all IPA servers are also trust controllers automatically, IIRC, but you
also do not need all of them to be for redundancy.

You may want to read
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/active-directory-trust
for a better understanding of what is involved in managing AD trusts, 5.1.6
explains the difference between trust controllers and trust agents.

HTH,
Simo.



> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: LDAP Replication errors and GSSAPI authentication on one FreeIPA replica

[Simo Sorce via FreeIPA-users]

On Wed, 2018-04-11 at 10:47 -0400, Dave Jablonski via FreeIPA-users
wrote:
> One of the FreeIPA replicas are not able to use the GSSAPI authentication
> to connect to ldap server on itself or any other FreeIPA server.  I'm not
> sure why.  I added example.com to just replace the actual domains, we're
> not using that.  I really don't fully understand how the krbprincipalname
> is used but as a thought I think maybe we have 2 ldap/ krbbprincipal names
> for this host/service and it's using the wrong one for the mapping.

Have you tried to install two servers with the same name at the same time by
chance ?
I do not see how else you'd get a duplicate entry in ldap woth the keytab.
Either that or you reinstalled a server while the topology had replication
issues that got resolved after the second reinstall.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Apache HTTPD with kerberized NFS4 document root

[Simo Sorce via FreeIPA-users]

On Tue, 2018-02-13 at 19:23 +0100, Ray via FreeIPA-users wrote:
> Hi Simo,
> 
> > > Hi Simo,
> > > 
> > > > > Hi there,
> > > > > 
> > > > > I'm trying to make Apache to access a kerberized document root on
> > > > > CentOS
> > > > > 7 using gssproxy. So far without success. On the web server machine
> > > > > (=NFS client) I configured a gss-proxy config file:
> > > > > 
> > > > > # cat /etc/gssproxy/99-nfs-client.conf
> > > > > [service/nfs-client]
> > > > >mechs = krb5
> > > > >cred_store = keytab:/etc/krb5.keytab
> > > > >cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
> > > > >cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
> > > > >cred_usage = initiate
> > > > >allow_any_uid = yes
> > > > >trusted = yes
> > > > >euid = 0
> > > > > 
> > > > > In addition to this I set up a credentials cache
> > > > > /var/lib/gssproxy/clients/krb5cc_
> > > > 
> > > > What did you put in this file?
> > > 
> > > Probably I made a mistake here: I got the keytab from the IPA server 
> > > and
> > > named it /var/lib/gssproxy/clients/krb5cc_ instead of
> > > /var/lib/gssproxy/clients/.keytab. I fixed that now (by
> > > mv'ing it) and ran
> > > 
> > >systemctl stop gssproxy to not have gssproxy as a 
> > > daemon
> > >gssproxy -d -i -C /etc/gssproxy/ &  to have gssproxy dump any debug
> > > msgs to my terminal
> > 
> > Note that running gssproxy from a root shell makes it run in unconfined
> > mode, so later on the files it create may have SELinux contexts that
> > are wrong and gssproxy may fail in various ways.
> 
> Ok, right now I switched SELinunx off (setenforce 0) until I have 
> somehting working...
> 
> > > # klist -ke .keytab
> > > Keytab name: FILE:.keytab
> > > KVNO Principal
> > > 
> > > --
> > > 1 nfs/ (aes256-cts-hmac-sha1-96)
> > > 1 nfs/ (aes128-cts-hmac-sha1-96)
> > > 1 host/ (aes256-cts-hmac-sha1-96)
> > > 1 host/ (aes128-cts-hmac-sha1-96)
> > 
> > This is not the keytab you want most probably.
> > You want a keytab with credentials that the server can map to a
> > UID/GID, usually that is done for user principals. However the server
> > can be configured to map a specific service principal name to a local
> > use as well, it's on the server side at this point.
> 
> I removed the above keytab and made a new one with user credentials:
> 
> # klist -ke .keytab
> Keytab name: FILE:.keytab
> KVNO Principal
>  
> --
> 2 @REALM (aes256-cts-hmac-sha1-96)
> 2 @REALM (aes128-cts-hmac-sha1-96)
> 
> This seems insufficient though, 'coz when I mount the NFS docroot 
> temporarily to /mnt and then "ls -l /" as httpd-user, I get to see this 
> line:
> 
> d??   ? ??   ?? mnt
> 
> Which other principals should I add to the keytab? I tried adding the 
> nfs service principal to the keytab, but that doesn't change this 
> behavior... Does the order in which I add principals to the keytab 
> matter in this context?

The first one is picked, and you have all you need there.

> klist for httpd-user looks not good either, concering the validy 
> timestamps (1970...1970), or is that normal?:
> 
> $ klist
> Ticket cache: KEYRING:persistent::
> Default principal: @REALM
> 
> Valid starting   Expires  Service principal
> 01/01/1970 01:00:00  01/01/1970 01:00:00  
> Encrypted/Credentials/v1@X-GSSPROXY:

It is an artifact of how Gssproxy stores credentials for you (in
encrypted form), it is normal, not a problem.

> > The (null) represents the default socket, not a bug.
> > 
> > Unfortunately the default log level does not show the result of the
> > calls, but it is  normal to see 2 init context calls, so it seem to be
> > working right on the gssproxy side.
> 
> I think there's something not right with gssproxy: when I call it with 
> --debug-level=3 it still says "level: 0":
> 
> # gssproxy --debug --debug-level=3 -i -C /etc/gssproxy/ &
> [1] 17831
> root@nfsclient:/var/lib/gssproxy/clients# [2018/02/13 09:56:20]: Debug 
> Enabled (level: 0)
> 
> Nevertheless the output becomes extremely verbose (plenty of hex). In 
> the man-page --debug-level is not mentioned at all (ok, still better 
> this way than having something promised in the manpage that does not 
> exist in the binary...).

Do you have any logs on the server side ?
As far as I can tell the client side (GSSAPI wise at least) is working
correctly.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Apache HTTPD with kerberized NFS4 document root

[Simo Sorce via FreeIPA-users]

Comment inline.

On Tue, 2018-02-13 at 16:58 +0100, Ray via FreeIPA-users wrote:
> Hi Simo,
> 
> > > Hi there,
> > > 
> > > I'm trying to make Apache to access a kerberized document root on 
> > > CentOS
> > > 7 using gssproxy. So far without success. On the web server machine
> > > (=NFS client) I configured a gss-proxy config file:
> > > 
> > > # cat /etc/gssproxy/99-nfs-client.conf
> > > [service/nfs-client]
> > >mechs = krb5
> > >cred_store = keytab:/etc/krb5.keytab
> > >cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
> > >cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
> > >cred_usage = initiate
> > >allow_any_uid = yes
> > >trusted = yes
> > >euid = 0
> > > 
> > > In addition to this I set up a credentials cache
> > > /var/lib/gssproxy/clients/krb5cc_
> > 
> > What did you put in this file?
> 
> Probably I made a mistake here: I got the keytab from the IPA server and 
> named it /var/lib/gssproxy/clients/krb5cc_ instead of 
> /var/lib/gssproxy/clients/.keytab. I fixed that now (by 
> mv'ing it) and ran
> 
>systemctl stop gssproxy to not have gssproxy as a daemon
>gssproxy -d -i -C /etc/gssproxy/ &  to have gssproxy dump any debug 
> msgs to my terminal

Note that running gssproxy from a root shell makes it run in unconfined
mode, so later on the files it create may have SELinux contexts that
are wrong and gssproxy may fail in various ways.

> After temporarily mounting the docroot to /mnt using
> 
>mount -vv -t nfs4 nfsserver:/path/to/export /mnt
> 
> I saw some debug messages flying by:
> 
> mount.nfs4: timeout set for Tue Feb 13 08:20:21 2018
> mount.nfs4: trying text-based options 
> 'vers=4.1,addr=,clientaddr='
> [2018/02/13 08:18:21]: Client connected (fd = 9)[2018/02/13 08:18:21]:  
> (pid = 623) (uid = 0) (gid = 0)[2018/02/13 08:18:21]:  (context = 
> system_u:system_r:gssd_t:s0)[2018/02/13 08:18:21]:
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) 
> for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 
> (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 
> (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) 
> for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 
> (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 
> (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) 
> for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 
> (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 
> (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) 
> for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 
> (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null)
> [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 
> (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null)
> 
> And when I then su to the apache user and try to access the directory, I 
> see some more debug messages:
> 
> # su -s /bin/bash 
> bash-4.2$ cd /mnt
> [2018/02/13 08:19:33]: Client connected (fd = 9)[2018/02/13 08:19:33]:  
> (pid = 623) (uid = ) (gid = )[2018/02/13 
> 08:19:33]:  (context = system_u:system_r:gssd_t:s0)[2018/02/13 
> 08:19:33]:
> [2018/02/13 08:19:33]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) 
> for service "nfs-client", euid: ,socket: (null)
> [2018/02/13 08:19:33]: gp_rpc_execute: executing 8 
> (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid:  uid>,socket: (null)
> [2018/02/13 08:19:34]: gp_rpc_execute: executing 8 
> (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid:  uid>,socket: (null)
> bash: cd: /mnt: Permission denied
> 
> Unfortunately still no success, as the last line indicates, however I 
> get to see a new /var/lib/gssproxy/clients/krb5cc_ file tat 
> was created by gssproxy, I presume:
> 
> -rw---. 1 root root 1819 Feb 13 08:19 krb5cc_
> 
> The keytab file /var/lib/gssproxy/clients/.keytab looks like 
> this:
> 
> # klist -ke .keytab
> Keytab name: FILE:.keytab
> KVNO Principal
>  
> --
> 1 nfs/ (aes256-cts-hmac-sha1-96)
> 1 nfs/ (aes128-cts-hmac-sha1-96)
> 1 host/ (aes256-cts-hmac-sha1-96)
> 1 host/ (aes128-cts-hmac-sha1-96)

This is not the keytab you want most probably.

[Freeipa-users] Re: Apache HTTPD with kerberized NFS4 document root

[Simo Sorce via FreeIPA-users]

On Tue, 2018-02-13 at 15:35 +0100, Ray via FreeIPA-users wrote:
> Hi there,
> 
> I'm trying to make Apache to access a kerberized document root on CentOS 
> 7 using gssproxy. So far without success. On the web server machine 
> (=NFS client) I configured a gss-proxy config file:
> 
> # cat /etc/gssproxy/99-nfs-client.conf
> [service/nfs-client]
>mechs = krb5
>cred_store = keytab:/etc/krb5.keytab
>cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
>cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
>cred_usage = initiate
>allow_any_uid = yes
>trusted = yes
>euid = 0
> 
> In addition to this I set up a credentials cache 
> /var/lib/gssproxy/clients/krb5cc_

What did you put in this file ?

> The Apache user is managed using FreeIPA and is a member of the exported 
> directory's group that shall be used as document root, hence it should 
> have access permissions to the directory and kinit for "apache" shows no 
> ticket.

Did you get a keytab for the apache user and place it in
/var/lib/gssproxy/clients/.keytab ?

> However, when I "su -s /bin/bash apache" and try to access the 
> NFS-mounted directory, I get permission denied (even with SELinux 
> temporarily disabled).
> 
> Right now, I do not see how I can proceed and there's not much meat on 
> the Google-bone for this specific topic. Can someone here point me into 
> the right direction?
> 
>* Is the config outlined the correct way to achieve what I want to do?

The configuration is correct, although you could tailor it specifically
to the apache process (setting a strinct euid not using allow_any_uid
nor trusted).

>* Is there a way to debug the issue I'm furrently facing?

You can raise the debug level of gssproxy to 3 and see what fails.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: timed out waiting on keys?

[Simo Sorce via FreeIPA-users]

I think this could be considered a bug, not sure if there is a ticket
open already, but I think someone else reported something similar
previously.

Simo.

On Mon, 2018-02-05 at 10:06 -0600, Kat wrote:
> Yes, D is CA
> 
> Firewalling is not 100% accurate. The masters are in different VPCs 
> across AWS AZ's. I use secure tunnels (stunnel) to connect the 
> master/replicas, which has worked fine for months. This is the 3rd VPC.  
> And in this case, rather than stunnel decided to peer the VPCs instead.
> 
> They are all DNS servers too, but because of the unique VPCs, used 
> "location" settings to have DNS work properly (this works great BTW)
> 
> -k
> 
> 
> On 2/5/18 09:58, Simo Sorce wrote:
> > On Sun, 2018-02-04 at 14:28 -0600, Kat via FreeIPA-users wrote:
> > > This is a new one I have not seen before.
> > > 
> > > Have 4 servers, trying to add a 5th.
> > > 
> > > Master A and B (in one location) can talk to C and D (in another location)
> > > 
> > > Trying to add E, which is a new location with the master to replicate
> > > from being D.
> > > 
> > > When I run client install, no issues at all.  Then I try to install E as
> > > a replica with DNS and CA setup and it gets almost all the way and ends
> > > up failing with (from the logs):
> > > 
> > > 2018-02-04T20:00:56Z DEBUG The ipa-replica-install command failed,
> > > exception: RuntimeError: Timed out trying to obtain keys.
> > > 2018-02-04T20:00:56Z ERROR Timed out trying to obtain keys.
> > > 
> > > It actually dies at:
> > > 
> > > Done configuring ipa-otpd.
> > > Configuring ipa-custodia
> > >     [1/4]: Generating ipa-custodia config file
> > >     [2/4]: Generating ipa-custodia keys
> > >     [3/4]: starting ipa-custodia
> > >     [4/4]: configuring ipa-custodia to start on boot
> > > Done configuring ipa-custodia.
> > > Your system may be partly configured.
> > > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > > 
> > > What is confusing, the log also shows that it times out waiting for keys
> > > to appear on "A", which it cannot get to because of location/firewall
> > > settings. What I don't understand, since I am building the replica off
> > > "D", why is it trying to communicate with A?
> > > 
> > > Any ideas on how to resolve this?
> > 
> > Is D a CA master ?
> > I think the replica installation code picks the first master it can
> > find, so it may be picking A (if that's a CA) in your case.
> > 
> > What's the reason to firewall off masters from each other ?
> > 
> > Simo.
> > 
> 
> 

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Accessing KRB5 NFS from local system accounts

[Simo Sorce via FreeIPA-users]

On Fri, 2017-12-01 at 11:15 -0800, Gordon Messmer via FreeIPA-users
wrote:
> On 12/01/2017 09:52 AM, Simo Sorce via FreeIPA-users wrote:
> > gssproxy dos not use libidmapd because it is not threads safe (among
> > other issues), it is also not needed, because you can control mapping
> > in auth_to_local in krb5.conf and that place is the correct place to
> > deal with identity mapping when kerberos is involved.
> 
> 
> Not sure if I'm doing this right, but that doesn't work for me, either:
> 
> [realms]
>    EXAMPLE.NET = {
>      pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
>      pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
>      auth_to_local = RULE:[2:$1](daemon)s/^.*$/daemon/
>      auto_to_local = DEFAULT
>    }
> 
> 
> Client's default principal is 
> daemon/application-2017111901.example@example.net

I think what you want is something like:
RULE:[2:$1@$0](dae...@example.net)s/.*//


note, this will map any daemon/@REALM principals to the
local 'daemon' user, be sure that's is ok.

This is a decent guide to better understand what can be done with
auth_to_local:
https://community.hortonworks.com/articles/14463/auth-to-local-rules-sy
ntax.html

HTH,
Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Accessing KRB5 NFS from local system accounts

[Simo Sorce via FreeIPA-users]

On Fri, 2017-12-01 at 14:34 +0100, Anton Semjonov wrote:
> On 01/12/17 00:11, Simo Sorce via FreeIPA-users wrote:
> > On Thu, 2017-11-30 at 14:50 -0800, Gordon Messmer via FreeIPA-users
> > wrote:
> > > I'm troubleshooting a problem: A local system account (daemon) needs to 
> > > access a file on an NFS4 filesystem with sec=krb5.  My understanding is 
> > > that only processes which have a Kerberos ticket are able to access 
> > > files on such a filesystem, and that seems to be the case on the system 
> > > I'm troubleshooting.
> > > 
> > > Suppose I need a keytab to identify the "daemon" user.  I don't think I 
> > > want to create a new user in FreeIPA, since it would have a uid/gid that 
> > > conflict with the locally defined account. However, I think I do need a 
> > > keytab for "daemon@DOMAIN".  The ipa command doesn't seem to provide a 
> > > means of creating such a principal.
> > > 
> > > Should I work directly in kadmin to create the principal and export the 
> > > keytab?  Am I even on the right track?
> > 
> > The reason why NFS wants to authenticate you, is to know what uig/gid
> > it should assign to your user (on the server) to access files. So
> > creating a user is not necessarily a bad idea...
> > 
> > However in some NFS servers you may be able to create mappings from
> > principals to local users. In that case you can use a SPN (Service
> > Principal Name) and associated keytab to gain access.
> > 
> > In freeipa only users can have a 1 component principal such as "daemon@
> > DOMAIN" normally. If you really just want to use a service I would
> > first explore the possibility of mapping "daemon/hosts.f.q.d.n@REALM"
> > to a user on the NFS server and then just create a normal service and
> > get a keytab for in in IPA.
> > 
> > Simo.
> > 
> 
> Could you elaborate on the mapping aspect? Specifically, what format do
> the static mappings in /etc/idmapd.conf need to be in in case of such
> service principals as you describe them?
> 
> As far as I can tell gssproxy works great for me and system users get
> their credential caches and so on .. but I'm stuck on id mapping.

gssproxy dos not use libidmapd because it is not threads safe (among
other issues), it is also not needed, because you can control mapping
in auth_to_local in krb5.conf and that place is the correct place to
deal with identity mapping when kerberos is involved.

HTH,
Simo.

> If I leave idmapd.conf at its defaults with no static mappings, the
> correct username is displayed on the client (e.g. apache) but the user
> is then denied access to files only readable by apache on the server. If
> I define a static mapping like
> 
> HTTP/client.$fqdn @ $REALM = apache
> 
> on the server and restart rpcidmapd.service, the owner of said files is
> mapped to nobody on the client, while the user has a credential cache
> for the service principal HTTP/client.$fqdn@$REALM. I am testing all of
> this by doing `su apache -s /bin/bash` on the client, btw.
> 
> However I do see lines like
> 
> rpc.idmapd[26077]: nfsdcb: authbuf=gss/krb5 authtype=user
> rpc.idmapd[26077]: Server : (user) id "48" -> name "HTTP/client.$fqdn"
> 
> in the server's journal. So I am not sure where things do break apart ..
> 
> - Anton

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Accessing KRB5 NFS from local system accounts

[Simo Sorce via FreeIPA-users]

On Thu, 2017-11-30 at 14:50 -0800, Gordon Messmer via FreeIPA-users
wrote:
> I'm troubleshooting a problem: A local system account (daemon) needs to 
> access a file on an NFS4 filesystem with sec=krb5.  My understanding is 
> that only processes which have a Kerberos ticket are able to access 
> files on such a filesystem, and that seems to be the case on the system 
> I'm troubleshooting.
> 
> Suppose I need a keytab to identify the "daemon" user.  I don't think I 
> want to create a new user in FreeIPA, since it would have a uid/gid that 
> conflict with the locally defined account. However, I think I do need a 
> keytab for "daemon@DOMAIN".  The ipa command doesn't seem to provide a 
> means of creating such a principal.
> 
> Should I work directly in kadmin to create the principal and export the 
> keytab?  Am I even on the right track?

The reason why NFS wants to authenticate you, is to know what uig/gid
it should assign to your user (on the server) to access files. So
creating a user is not necessarily a bad idea...

However in some NFS servers you may be able to create mappings from
principals to local users. In that case you can use a SPN (Service
Principal Name) and associated keytab to gain access.

In freeipa only users can have a 1 component principal such as "daemon@
DOMAIN" normally. If you really just want to use a service I would
first explore the possibility of mapping "daemon/hosts.f.q.d.n@REALM"
to a user on the NFS server and then just create a normal service and
get a keytab for in in IPA.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: restrict parallel ssh logins on different freeipa systems

[Simo Sorce via FreeIPA-users]

On Mon, 2017-11-27 at 21:42 +0100, Michael Frank via FreeIPA-users
wrote:
> Hi,
> 
> we run freeipa based on red hat 7.3 
> It is possible to determine if a certain user (idm user who can become root 
> via sudo) is logged in on multiple idm machines 
> and restrict for the user that only *one* login on a single server at the 
> same time is allowed ?
> 
> Any hints how to do this - or - is there something „built-in“ ?

not possible in freeIPA and not something we'd likely implement.

However it should be relatively simple to build a pam service that
enforces that by contacting a custom service.

The devil is in the "denial of service" details, you need to build
something very robust that does not completely disrupt your environment
and allows for nuanced exceptions.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Enrolling SLE 12 SP2 hosts with FreeIPA

[Simo Sorce via FreeIPA-users]

On Tue, 2017-10-24 at 16:23 +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the FreeIPA List,
> 
>  
> 
> We've got a FreeIPA directory set up and running. That's all good.
> 
>  
> 
> The difficult part is that we also have a number (many) of SLE 12 SP2
> hosts
> that need to be enrolled.
> 
>  
> 
> I can see that the freeipa-client package has not been available to
> SLE/SUSE
> since 2015 or so, so the ipa-client-install, ipa-join, and ipa-
> getkeytab
> tools are unavailable. They would be nice, we'd just do a check and
> execute
> it when host is redeployed to enroll and configure the host.
> 
>  
> 
> We've manage to figure out the static parts of the required
> configuration
> (/etc/nsswitch.conf /etc/sssd/sssd.conf and /etc/krb5.conf) as well
> as
> deploying the FreeIPA server's certificate to /etc/ipa/ca.crt. We can
> also
> enroll the hosts 'remotely' by scripting over their hostnames and IP
> addresses from a CSV file, so the exist in the FreeIPA directory and
> even
> join them to some hostgroups.
> 
>  
> 
> The bit we're a bit stuck at is retrieving the host's Kerberos
> keytab. There
> does not seem to be a getkeytab request for the FreeIPA API, and the
> use of
> kadmin and ktutil to process the keytab is not recommended.

Use ipa-getkeytab on an admin workstation, then securely transfer the
keytab to the servers.


> We need a stepwise process to run on the host being enrolled that
> gets the
> keytab from the FreeIPA directory and installs it into the host.
> 
>  
> 
> At the moment the method that looks like it's going to work is to
> write a
> script that ssh to the FreeIPA server, kinit as a user who can
> retrieve
> keytabs, get the keytab and write to a temporary file, scp the keytab
> back
> to the host, tidy up temp files, then return to the host, validate
> the
> keytab, install it, and restart Kerberos/sshd/sssd.

This may work also.

>  
> 
> This seems less than ideal, alternatively should we look a compiling
> the ipa-client into a package?

In the freeIPA git repo there is, in the spec file, a variable that
allows you to compile only the client bits IIRC. You should be able to
compile that for SLES.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: IPA policy creation

[Simo Sorce via FreeIPA-users]

On Wed, 2017-10-11 at 10:41 -0400, Mark Haney wrote:
> On 10/10/2017 05:46 PM, Simo Sorce wrote:
> > 
> > > 
> > > Could you perhaps do something weird with the default shell
> > > setting?
> > 
> > probably can use oddjob/oddjob_mkhomedir properly configured on the
> > various servers.
> > 
> > Simo.
> > 
> 
> Actually it was even simpler than that, and goes to show what
> happens 
> when you over-think things.  As this was on a server that needed all 
> home directories to have this symlink, I just added it to the
> skeleton 
> directory.  I really feel like an idiot for not thinking about that. 
> I 
> haven't had to mess with /etc/skel in so long, it never crossed my
> mind 
> until I read the oddjobd_mkhomedir man page.  I hate getting old.
> 

This is what I meant with "properly configured" :-)

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: IPA policy creation

[Simo Sorce via FreeIPA-users]

On Tue, 2017-10-10 at 17:36 -0400, Robbie Harwood via FreeIPA-users
wrote:
> Rob Crittenden writes:
> 
> > Mark Haney via FreeIPA-users wrote:
> > 
> > > Due to people not documenting squat here over years, one of our
> > > servers configurations got jacked up when I migrated it from
> > > OpenLDAP
> > > to IPA.  This is a CentOS 6 server that runs RANCID to pull
> > > customer
> > > edge router configs.  The old OpenLDAP setup had a policy in
> > > Kerberos
> > > that would create a symlink to the RANCID backup directory in the
> > > home directory of a new user account upon first login.  Is it
> > > possible to set this up in IPA?  If so, are there docs/how tos on
> > > doing this?
> > > 
> > > I would assume it's an IPA policy, but I'm not sure how similar
> > > it
> > > would be to doing it in OpenLDAP/Kerberos.
> > > 
> > 
> > Unfortunately there is no way to specify scripts upon user login
> > (first or otherwise) in IPA currently.
> 
> Could you perhaps do something weird with the default shell setting?

probably can use oddjob/oddjob_mkhomedir properly configured on the
various servers.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can't log on using password when /tmp is full

[Simo Sorce via FreeIPA-users]

On Tue, 2017-09-19 at 14:37 -0400, Simo Sorce via FreeIPA-users wrote:
> We normally store credentials in the kernel keyring, have you changed
> the default ccache type in your installation ?

Ignore the above, I overlooked that you are on RHEL6, we introduced the
keyring in RHEL7.

Simo.

> If you have elected to use /tmp to store ccaches and it is full it is
> expected for auth to fail.
> 
> Simo.
> 
> On Mon, 2017-09-18 at 17:11 +0200, Marius Bjørnstad via FreeIPA-users
> wrote:
> > Hi,
> > 
> > When /tmp is full, it is impossible to authenticate with Kerberos.
> > Login with password over SSH and sudo don't work. Login with ssh
> > key
> > works fine. Here is the output in the system log when I try to log
> > on
> > via SSH with password auth (this is on RHEL 6):
> > 
> > Sep 18 16:56:59 vali sshd[35157]: Set /proc/self/oom_score_adj to 0
> > Sep 18 16:56:59 vali sshd[35157]: Connection from 192.168.1.48 port
> > 49917
> > Sep 18 16:57:02 vali [sssd[krb5_child[35165]]]: Credentials cache
> > I/O
> > operation failed XXX
> > Sep 18 16:57:02 vali [sssd[krb5_child[35165]]]: Credentials cache
> > I/O
> > operation failed XXX
> > Sep 18 16:57:04 vali sshd[35157]: Failed password for paalmbj from
> > 192.168.1.48 port 49917 ssh2
> > Sep 18 16:57:07 vali sshd[35158]: Connection closed by 192.168.1.48
> > 
> > From SSH I get:
> > Permission denied, please try again.
> > 
> > The problem seems to be that Kerberos can't store its credentials
> > cache. Is this normal, and is there a way around it? Sure, ideally
> > I
> > should limit the space usable by each user, but that doesn't help
> > when a given user needs to log in and fix their tmp usage.
> > 
> > Thanks,
> > Marius
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.fedorahos
> > te
> > d.org
> 
> -- 
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahoste
> d.org

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Replacing OpenLDAP with FreeIPA

[Simo Sorce via FreeIPA-users]

On Fri, 2017-09-08 at 12:36 -0400, Mark Haney wrote:
> On 09/08/2017 12:10 PM, Simo Sorce wrote:
> > On Fri, 2017-09-08 at 10:06 -0400, Mark Haney via FreeIPA-users
> > wrote:
> > > Probably the dumbest question you'll get all day, but we've got a
> > > hundred or so VMs with OpenLDAP on them (as clients pointing to a
> > > master).  Are there any gotchas to replacing OpenLDAP with
> > > FreeIPA?
> > 
> > Do you mean that you are replicating your whole ldap directory on
> > each
> > client ?
> 
> Unfortunately, yes in the case of the boxes we supply to our
> customers. 
> Disclaimer:  This was decided on LONG before I arrived and never
> really 
> worked well anyway, hence the need to do it right this time.

eeek :)

> > >    I'm
> > > using Ansible to push the client install to the VMs, with a task
> > > for
> > > uninstalling OpenLDAP prior to IPA setup.
> > > 
> > > Does this plan sound cunning enough?  Or am I missing something?
> > 
> > ENOINFO to comment on whether this is genius or madness :-)
> 
> Maybe I should clarify.  We're moving away from a full OpenLDAP
> server 
> running on customer servers (which is really small, mainly the 5 or
> 6 
> Operations accounts that need logins) and replacing it with FreeIPA 
> client setups.  The Ansible playbook would be (more or less) 3 tasks:
> 
> Uninstall openldap-servers package (these are all Centos 6 boxes)
> Install freeipa-client
> Run the unattended setup with all settings passed as variables.
> 
> I can't see any issues with this method, but I like having other eyes
> go 
> over it when it's something I've never had to do before.

Sounds like a nice upgrade :-)
If the data is the same I see no issue on the general approach.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Replacing OpenLDAP with FreeIPA

[Simo Sorce via FreeIPA-users]

On Fri, 2017-09-08 at 10:06 -0400, Mark Haney via FreeIPA-users wrote:
> Probably the dumbest question you'll get all day, but we've got a 
> hundred or so VMs with OpenLDAP on them (as clients pointing to a 
> master).  Are there any gotchas to replacing OpenLDAP with FreeIPA?

Do you mean that you are replicating your whole ldap directory on each
client ?

>   I'm 
> using Ansible to push the client install to the VMs, with a task for 
> uninstalling OpenLDAP prior to IPA setup.
> 
> Does this plan sound cunning enough?  Or am I missing something?

ENOINFO to comment on whether this is genius or madness :-)

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: logging

[Simo Sorce via FreeIPA-users]

On Fri, 2017-08-11 at 15:27 +, Andrew Meyer via FreeIPA-users
wrote:
> If I want to keep track of DNS changes in FreeIPA, is there  a way to
> do this?

You could run a peristent serach against the DNS subtree and funnel the
output in some log file.
You would see all the changes as ldif snippets.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: keytab usage?

[Simo Sorce via FreeIPA-users]

On Mon, 2017-06-05 at 09:59 -0500, Kat via FreeIPA-users wrote:
> Never mind -- if I use ipa-getkeytab, it works perfectly.
> 
> What is the difference between what getkeytab and ktutil by hand
> does? 
> Is it documented?

In FreeIPA we generate a random salt instead of using the old
"principal name as salt". ktutil depends on using the "principal name
as salt" to generate correct keys, so it fails to create a valid key.

Simo.

> -K
> 
> 
> On 6/5/17 9:18 AM, Kat wrote:
> > Ok, I guess I am not understanding something here. What am I
> > missing? 
> > The PW is correct, but no matter what I do, I can't use the keytab 
> > file for a user as shown below:
> > 
> > [root@ipa ~]# ktutil
> > ktutil:  addent -password -p cyb...@example.com -k 1 -e 
> > aes256-cts-hmac-sha1-96
> > Password for cyb...@example.com:
> > ktutil:  wkt /root/cyberj.keytab
> > ktutil:  q
> > 
> > [root@ipa ~]# kinit -k -t cyberj.keytab cyb...@example.com
> > kinit: Password incorrect while getting initial credentials
> > 
> > :-(
> > 
> > -K
> > 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahoste
> d.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Setting up IPA server on an already domain joined machine

[Simo Sorce via FreeIPA-users]

On Mon, 2017-05-22 at 10:17 +, doug.ke...@wipro.com wrote:
> Hi,
> 
> 
> I'm wondering if anyone else has done something similar to us, and if so am 
> wondering how you went about it or if it is indeed at all possible.
> 
> 
> Our situation is:
> 
> 
>   *   We have a few VMs which are domain joined to "internal.local" which is 
> an Active Directory domain that we have no control over or administrative 
> access
>   *   We would like to install IPA on these VMs (replicated, with named for 
> DNS) with a separate domain called "dev.zone"
>   *   Authentication to the VM itself via SSH should be carried out against 
> "internal.local" still – we will point our own services that we are going to 
> install like GitLab directly at the IPA server
>   *   "dev.zone" will be setup as a conditional forwarder on the Active 
> Directory domain pointing at the IPA-installed named-pkcs11 service to do 
> resolution for this domain
> 
> 
> My initial findings are that IPA installs fine but it changes some things in 
> /etc/krb5.conf like:
> 
> 
>   *   Adding in "dev.zone" realm
>   *   Modifies the "default_realm" to be "dev.zone"
>   *   Leaves the "[realm]" definition for "internal.local" but empties it of 
> the "kdc" and "admin_server" definitions
>   *   Removes the kerberos tickets for "internal.local" that were in "net ads 
> keytab list"
> 
> 
> This ultimately results in IPA working fine but authentication to the server 
> via SSH no longer works as it's looking to "dev.zone" now.
> 
> 
> Is it possible to achieve what we're wanting to do? Can these two things 
> co-exist peacefully?

Doug,
it may be possible with custom scripts, but it will probably not be a
very stable solution as upgrades may change things in unexpected ways.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: krbLastSuccessfulAuth

[Simo Sorce via FreeIPA-users]

On Tue, 2017-05-23 at 13:07 -0400, Chris Apsey via FreeIPA-users wrote:
> All,
> 
> We use freeIPA as the LDAP backend for OpenStack Keystone, GitLab, and a 
> few other things.  We have been looking for a way to keep track of the 
> last time a user logged on, and the obvious answer seems to be the 
> krbLastSuccessfulAuth attribute.  The problem is that this value for all 
> users is N/A:
> 
> ---
> Account disabled: False
> ---
>Server: {{srv}}
>Failed logins: 0
>Last successful authentication: N/A
>Last failed authentication: N/A
>Time now: 2017-05-23T16:47:49Z
> 
> Number of entries returned 1
> 
> 
> I checked to make sure that the ipaConfigString doesn't contain 
> KDC:Disable Last Success.  Does krbLastSuccessfulAuth only get updated 
> when using kerberized logins?  If so, is there a way to track the last 
> time a user successfully authenticated via pure LDAP (besides parsing 
> logs)?

As the name krbLastSuccessfulAuth implies we update this only on a
successful kerberos login (and I think we do not replicate it by
default, as it would cause a lot of replication overhead).

I think atm parsing logs is the only way, it may be nice to have an RFE
open to track the need to have a consolidated log/queue where we can
emit messages when someone (un)successfully logs in.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org