Re: [Freeipa-users] sudo (sssd) hangs due to ipa install/uninstall scripts

[Prasun Gera]

Just writing to say that the automount scripts still seem to be quite
broken in RHEL 7.3. I did a couple of client installs recently, and
ipa-client-automount
--install completed successfully, but didn't add sss to /etc/nsswitch.conf.
By now, I've got used to this pattern. So I look for the presence or
absence of sss in nsswitch.conf after running any of these scripts, since
that seems to be the most common issue.

On Thu, Sep 3, 2015 at 3:17 AM, Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On Wed, 02 Sep 2015, Prasun Gera wrote:
>
>> I have zero confidence in any of the install and uninstall scripts. And
>> this is on RHEL systems. On unofficial ones like Ubuntu, things are even
>> more broken. I really like freeipa, but so far even in a smallish lab
>> environment, it has been a nightmare. I am really tempted to just go back
>> to NIS. Does anyone have any ideas or proposals for making things more
>> robust ? At the very least, I think that these sort of modifications to
>> system files should only happen with package install/removal. Any changes
>> that ipa's scripts do should be local to ipa's internal state. Better
>> would
>> be to have an internal ipa database sort of thing which keeps track of
>> what
>> the current state is so that even if a script dies, which has happened
>> often, the next attempt reads the database and figures out what happened
>> earlier.
>>
> File bugs with enough details. It is the only reliable way to fix any
> issues where environments differ. Install/uninstall scripts work for
> fresh installs in RHEL and Fedora because this is what is tested. If you
> have repurposed machines from some other setups, things might differ and
> only you know what is in your environment.
>
> That's not bad or good, that's just different -- the more different
> environments we see, more robust code can be added. People are
> infinitely more clever than computers when it comes to configuration
> files' format mangling.
>
> I've seen multiple cases where a claim of 'ipa scripts broke my
> configuration' was later retracted saying that puppet or other SCM run
> afterwards did these changes. That just happen, if there are many
> elephants dancing in the room, a careful coordination is always a good
> idea.
>
> Coming back to your issues, please file bugs -- either upstream or
> downstream, via distributions, whatever way is more suitable to you.
> Contributing 'broken' config files would be good too.
>
>
> --
> / Alexander Bokovoy
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera]

Any ideas why the replica's certs are not being tracked ? That looks like
an issue in itself. If they are not being tracked, the replica will fail
once they expire. Is there any way to fix the replica ?

On Sun, Apr 23, 2017 at 10:08 PM, Prasun Gera <prasun.g...@gmail.com> wrote:

> I tried that, but the replica's "getcert list" doesn't seem to show any
> results. "Number of certificates and requests being tracked: 0." Is that
> expected ?
>
> On Sun, Apr 23, 2017 at 8:50 PM, Fraser Tweedale <ftwee...@redhat.com>
> wrote:
>
>> On Sun, Apr 23, 2017 at 03:32:19AM -0400, Prasun Gera wrote:
>> > Thank you. That worked for the master. How do I fix the replica's cert ?
>> > This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not using
>> > ipa's DNS at all. Did this happen because of that ?
>> >
>> This is not related to DNS.
>>
>> To fix the replica, log onto the host and perform the same steps
>> with Certmonger there.  The tracking Request ID will be different
>> but otherwise the process is the same.
>>
>> Cheers,
>> Fraser
>>
>> > On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale <ftwee...@redhat.com>
>> > wrote:
>> >
>> > > On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote:
>> > > > I can confirm that I see this behaviour too. My ipa server install
>> is a
>> > > > pretty stock install with no 3rd party certificates.
>> > > >
>> > > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
>> > > > simon.willi...@thehelpfulcat.com> wrote:
>> > > >
>> > > > > Yesterday, Chrome on both my Ubuntu and Windows machines updated
>> to
>> > > > > version 58.0.3029.81.  It appears that this version of Chrome
>> will not
>> > > > > trust certificates based on Common Name.  Looking at the Chrome
>> > > > > documentation and borne out by one of the messages, from Chrome
>> 58,
>> > > > > the subjectAltName is required to identify the DNS name of the
>> host
>> > > that
>> > > > > the certificate is issued for.  I would be grateful if someone
>> could
>> > > point
>> > > > > me in the direction of how to recreate my SSL certificates so that
>> > > > > the subjectAltName is populated.
>> > > > >
>> > > > > Thanks in advance
>> > > > >
>> > > > > --
>> > > > > Manage your subscription for the Freeipa-users mailing list:
>> > > > > https://www.redhat.com/mailman/listinfo/freeipa-users
>> > > > > Go to http://freeipa.org for more info on the project
>> > > > >
>> > > Which version of IPA are you using?
>> > >
>> > > The first thing you should do, which I think should be sufficient in
>> > > most cases, is to tell certmonger to submit a new cert request for
>> > > each affected certificate, instructing to include the relevant
>> > > DNSName in the subjectAltName extension in the CSR.
>> > >
>> > > To list certmonger tracking requests and look for the HTTPS
>> > > certificate.  For example:
>> > >
>> > > $ getcert list
>> > > Number of certificate and requests being tracked: 11
>> > > ...
>> > > Request ID '20170418012901':
>> > > status: MONITORING
>> > > stuck: no
>> > > key pair storage: type=NSSDB,location='/etc/
>> > > httpd/alias',nickname='Server-Cert',token='NSS Certificate
>> > > DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>> > > certificate: type=NSSDB,location='/etc/
>> > > httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'
>> > > CA: IPA
>> > > issuer: CN=Certificate Authority,O=IPA.LOCAL 201703211317
>> > > subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317
>> > > expires: 2019-03-22 03:20:19 UTC
>> > > dns: f25-2.ipa.local
>> > > key usage: digitalSignature,nonRepudiatio
>> n,keyEncipherment,
>> > > dataEncipherment
>> > > eku: id-kp-serverAuth,id-kp-clientAuth
>> > > pre-save command:
>> > > post-save command: /usr/libexec/ipa/certmonger/re
>> start_httpd
>> > > track: yes
>> > > auto-renew: yes
>> > > ...
>> > >
>> > > Using the Request ID of the HTTPS certificate, resubmit the request
>> > > but use the ``-D `` option to specify a DNSName to include
>> > > in the SAN extension:
>> > >
>> > >   $ getcert resubmit -i  -D 
>> > >
>> > > ``-D `` can be specified multiple times, if necessary.
>> > >
>> > > This should request a new certificate that will have the server DNS
>> > > name in the SAN extension.
>> > >
>> > > HTH,
>> > > Fraser
>> > >
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] List SPAM

[Prasun Gera]

Yes, I am aware of the workarounds, and went through the exact same steps
that you mentioned several times. This is clearly not a solution. Can
someone from the team comment on why email addresses are published in the
first place ? I do not see any advantages and plenty of disadvantages. Spam
notwithstanding, I am not a big fan of the email being published at all.

On Thu, Apr 27, 2017 at 11:10 PM, Lachlan Musicman <data...@gmail.com>
wrote:

> On 24 April 2017 at 12:24, Prasun Gera <prasun.g...@gmail.com> wrote:
>
>> That doesn't work very well. The spam bots use different emails. And
>> gmail marks the entire message thread as spam, not just the spam reply.
>>
>> On Sun, Apr 23, 2017 at 7:20 AM, Dewangga Bachrul Alam <
>> dewangg...@xtremenitro.org> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Mark as spam, and they gone from my inbox. :)
>>>
>>>
>
>
> If you are using gmail:
>
>  - block the email address
>  - mark the message as spam (not the thread)
>  - you can then delete the message in question
>
>
> Note that this can still cause issues wrt workplace and SFW images, as
> Gmail automatically "previews" images.
>
> I leave them to deal with at home and have reported the problem to my
> manager and IT team so they know it's not my fault - as both acknowledge
> and understand that this forum has been very valuable to us wrt getting
> things working.
>
> L.
>
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
>
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] List SPAM

[Prasun Gera]

That doesn't work very well. The spam bots use different emails. And gmail
marks the entire message thread as spam, not just the spam reply.

On Sun, Apr 23, 2017 at 7:20 AM, Dewangga Bachrul Alam <
dewangg...@xtremenitro.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark as spam, and they gone from my inbox. :)
>
> On 04/23/2017 05:10 PM, Prasun Gera wrote:
> > This still continues to be a problem. Was any solution identified
> > for this ? Why are the emails not obfuscated on the public archives
> > ?
> >
> > On Tue, Dec 27, 2016 at 7:32 AM, Martin Basti <mba...@redhat.com
> > <mailto:mba...@redhat.com>> wrote:
> >
> >
> >
> > On 27.12.2016 13:22, Outback Dingo wrote:
> >
> > Im still getting nude porn spam emails and pics from a user
> >
> > Kimi Rachel <kimirachel3...@ryfen.com
> > <mailto:kimirachel3...@ryfen.com>>
> >
> >
> > It is not a user, it is a SPAM bot mining public archives. We
> > don't have any control about it we can just un-publish archives
> > (tested, spam stopped after that) but they contain a lot of
> > information for users.
> >
> > JFTR the email is changing.
> >
> >
> > -- Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > <https://www.redhat.com/mailman/listinfo/freeipa-users> Go to
> > http://freeipa.org for more info on the project
> >
> >
> >
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQI4BAEBCAAiBQJY/I3kGxxkZXdhbmdnYWJhQHh0cmVtZW5pdHJvLm9yZwAKCRDl
> f9IgoCjNcLLgEAChyD/U8wlcTlwjiWgcbyLOcwrFsfvJ1HKUKPi4+fh3VDtX1iQF
> XwSyxeMch+obLEraKXI01+rpk6cgxg2xWnhxcUOobsVPzFoQVFnYU9+Ngxpgajx9
> XRigMU4lxwBf33IO3DOM7iUGdw4DfRaVZ5H3UUv/6JaQmxwyL6rmxVjcbhMFBcnG
> p6Mw+xzsWlIgmf5Kz8e/Eu3pxZXgrxOddtI5z9e7ApZiRavtdi5SuNIEHPsVNC0j
> 6P2eNA/zK3E3IpfknWB2wCoR2+gB/1fYzP71iz55exy3Sefnv0CLpjnhRoPsuzVm
> iiFeBF64KOYWmK0Uw3ftfNEw67bHPcvlnba4Ftj2PsTkwupH9/RpccQ0t9yOl+gi
> fdmY7s91MdODNXiKR5GG/bT5JPyBE5VtkufZIqJDLliqn1kVkCLqSgOLZyQflhI6
> 2pZLHufBMiMGKgdEfSx1DdqmPILLqlIhr+kqAn0qtyIDlz1jV5cic9issi4Z/aWi
> MVECMBkPu5kNnANVKBz2YjbL8LD/Dr15R2WZVH7drzAc4Byo88DRpwESSqS0W4hX
> ai1nVTxyD8CdW8Ab63rLwmvF8li39V1Xse2hiinntaYa/Ap6/WFNOR7Qyon5yxnG
> /AFpAgtWgH0rjnNMNnYZO3Ck7hpSgdCCgqOTOKc+3FHqqcg+K7uckqdswg==
> =G2rj
> -END PGP SIGNATURE-
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera]

I tried that, but the replica's "getcert list" doesn't seem to show any
results. "Number of certificates and requests being tracked: 0." Is that
expected ?

On Sun, Apr 23, 2017 at 8:50 PM, Fraser Tweedale <ftwee...@redhat.com>
wrote:

> On Sun, Apr 23, 2017 at 03:32:19AM -0400, Prasun Gera wrote:
> > Thank you. That worked for the master. How do I fix the replica's cert ?
> > This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not using
> > ipa's DNS at all. Did this happen because of that ?
> >
> This is not related to DNS.
>
> To fix the replica, log onto the host and perform the same steps
> with Certmonger there.  The tracking Request ID will be different
> but otherwise the process is the same.
>
> Cheers,
> Fraser
>
> > On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale <ftwee...@redhat.com>
> > wrote:
> >
> > > On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote:
> > > > I can confirm that I see this behaviour too. My ipa server install
> is a
> > > > pretty stock install with no 3rd party certificates.
> > > >
> > > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
> > > > simon.willi...@thehelpfulcat.com> wrote:
> > > >
> > > > > Yesterday, Chrome on both my Ubuntu and Windows machines updated to
> > > > > version 58.0.3029.81.  It appears that this version of Chrome will
> not
> > > > > trust certificates based on Common Name.  Looking at the Chrome
> > > > > documentation and borne out by one of the messages, from Chrome 58,
> > > > > the subjectAltName is required to identify the DNS name of the host
> > > that
> > > > > the certificate is issued for.  I would be grateful if someone
> could
> > > point
> > > > > me in the direction of how to recreate my SSL certificates so that
> > > > > the subjectAltName is populated.
> > > > >
> > > > > Thanks in advance
> > > > >
> > > > > --
> > > > > Manage your subscription for the Freeipa-users mailing list:
> > > > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > > > > Go to http://freeipa.org for more info on the project
> > > > >
> > > Which version of IPA are you using?
> > >
> > > The first thing you should do, which I think should be sufficient in
> > > most cases, is to tell certmonger to submit a new cert request for
> > > each affected certificate, instructing to include the relevant
> > > DNSName in the subjectAltName extension in the CSR.
> > >
> > > To list certmonger tracking requests and look for the HTTPS
> > > certificate.  For example:
> > >
> > > $ getcert list
> > > Number of certificate and requests being tracked: 11
> > > ...
> > > Request ID '20170418012901':
> > > status: MONITORING
> > > stuck: no
> > > key pair storage: type=NSSDB,location='/etc/
> > > httpd/alias',nickname='Server-Cert',token='NSS Certificate
> > > DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> > > certificate: type=NSSDB,location='/etc/
> > > httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'
> > > CA: IPA
> > > issuer: CN=Certificate Authority,O=IPA.LOCAL 201703211317
> > > subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317
> > > expires: 2019-03-22 03:20:19 UTC
> > > dns: f25-2.ipa.local
> > > key usage: digitalSignature,nonRepudiation,
> keyEncipherment,
> > > dataEncipherment
> > > eku: id-kp-serverAuth,id-kp-clientAuth
> > > pre-save command:
> > > post-save command: /usr/libexec/ipa/certmonger/
> restart_httpd
> > > track: yes
> > > auto-renew: yes
> > > ...
> > >
> > > Using the Request ID of the HTTPS certificate, resubmit the request
> > > but use the ``-D `` option to specify a DNSName to include
> > > in the SAN extension:
> > >
> > >   $ getcert resubmit -i  -D 
> > >
> > > ``-D `` can be specified multiple times, if necessary.
> > >
> > > This should request a new certificate that will have the server DNS
> > > name in the SAN extension.
> > >
> > > HTH,
> > > Fraser
> > >
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] List SPAM

[Prasun Gera]

This still continues to be a problem. Was any solution identified for this
? Why are the emails not obfuscated on the public archives ?

On Tue, Dec 27, 2016 at 7:32 AM, Martin Basti  wrote:

>
>
> On 27.12.2016 13:22, Outback Dingo wrote:
>
>> Im still getting nude porn spam emails and pics from a user
>>
>> Kimi Rachel 
>>
>>
> It is not a user, it is a SPAM bot mining public archives. We don't have
> any control about it we can just un-publish archives (tested, spam stopped
> after that) but they contain a lot of information for users.
>
> JFTR the email is changing.
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera]

Thank you. That worked for the master. How do I fix the replica's cert ?
This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not using
ipa's DNS at all. Did this happen because of that ?

On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale <ftwee...@redhat.com>
wrote:

> On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote:
> > I can confirm that I see this behaviour too. My ipa server install is a
> > pretty stock install with no 3rd party certificates.
> >
> > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
> > simon.willi...@thehelpfulcat.com> wrote:
> >
> > > Yesterday, Chrome on both my Ubuntu and Windows machines updated to
> > > version 58.0.3029.81.  It appears that this version of Chrome will not
> > > trust certificates based on Common Name.  Looking at the Chrome
> > > documentation and borne out by one of the messages, from Chrome 58,
> > > the subjectAltName is required to identify the DNS name of the host
> that
> > > the certificate is issued for.  I would be grateful if someone could
> point
> > > me in the direction of how to recreate my SSL certificates so that
> > > the subjectAltName is populated.
> > >
> > > Thanks in advance
> > >
> > > --
> > > Manage your subscription for the Freeipa-users mailing list:
> > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > > Go to http://freeipa.org for more info on the project
> > >
> Which version of IPA are you using?
>
> The first thing you should do, which I think should be sufficient in
> most cases, is to tell certmonger to submit a new cert request for
> each affected certificate, instructing to include the relevant
> DNSName in the subjectAltName extension in the CSR.
>
> To list certmonger tracking requests and look for the HTTPS
> certificate.  For example:
>
> $ getcert list
> Number of certificate and requests being tracked: 11
> ...
> Request ID '20170418012901':
> status: MONITORING
> stuck: no
> key pair storage: type=NSSDB,location='/etc/
> httpd/alias',nickname='Server-Cert',token='NSS Certificate
> DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: type=NSSDB,location='/etc/
> httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=IPA.LOCAL 201703211317
> subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317
> expires: 2019-03-22 03:20:19 UTC
> dns: f25-2.ipa.local
> key usage: digitalSignature,nonRepudiation,keyEncipherment,
> dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:
> post-save command: /usr/libexec/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes
> ...
>
> Using the Request ID of the HTTPS certificate, resubmit the request
> but use the ``-D `` option to specify a DNSName to include
> in the SAN extension:
>
>   $ getcert resubmit -i  -D 
>
> ``-D `` can be specified multiple times, if necessary.
>
> This should request a new certificate that will have the server DNS
> name in the SAN extension.
>
> HTH,
> Fraser
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera]

I can confirm that I see this behaviour too. My ipa server install is a
pretty stock install with no 3rd party certificates.

On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
simon.willi...@thehelpfulcat.com> wrote:

> Yesterday, Chrome on both my Ubuntu and Windows machines updated to
> version 58.0.3029.81.  It appears that this version of Chrome will not
> trust certificates based on Common Name.  Looking at the Chrome
> documentation and borne out by one of the messages, from Chrome 58,
> the subjectAltName is required to identify the DNS name of the host that
> the certificate is issued for.  I would be grateful if someone could point
> me in the direction of how to recreate my SSL certificates so that
> the subjectAltName is populated.
>
> Thanks in advance
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IDM server doesn't boot after update to RHEL 7.3

[Prasun Gera]

Any systemd experts that can help in figuring out what's going on here ?

Here's a shortened log up to that error if it makes it more convenient:
https://gist.github.com/pgera/00f1ae31f77b9e9aa652db2be0e29574

On Fri, Feb 17, 2017 at 8:40 PM, Prasun Gera <prasun.g...@gmail.com> wrote:

> I now have a detailed debug log for this failed boot which I've attached
> with the mail. The issue seems to be specific to this system. The replica
> was updated to 7.3 too, and it works fine. I've zipped the log because it's
> quite big. The original workaround still holds true. i.e. I boot in rescue
> mode, start sssd, and then call isolate graphical.target which makes
> everything work normally. With the graphical target as default, the system
> doesn't boot. Somehow sssd is involved in the mix.
>
> Can someone please have a look at the log ?
>
> On Thu, Nov 10, 2016 at 12:53 PM, Prasun Gera <prasun.g...@gmail.com>
> wrote:
>
>> Yes, from my experiments, it gets stuck at some point where it has to
>> start avahi. And it fails to start it because it is dependent on something
>> that is not started yet (which is started when sssd is started). Googling
>> for that error pointed took me to http://www.calculate-linux.org
>> /boards/15/topics/26673, which seems to be somewhat related I
>> think. I'll post the journal messages soon. Is there some sort of a systemd
>> diff utility which can compare the start sequence of services from two
>> different systems ? Since my replica is on 7.2, which afaik works fine,
>> doing a diff between the two might highlight if something has changed in
>> the start sequence.
>>
>> On Thu, Nov 10, 2016 at 12:35 PM, Petr Vobornik <pvobo...@redhat.com>
>> wrote:
>>
>>> On 11/09/2016 12:53 PM, Prasun Gera wrote:
>>> > It looks like something is messed up in the systemd configuration
>>> after 7.3. My
>>> > system doesn't boot at all. The boot screen would display the message:
>>> "Failed
>>> > to register match for Disconnected message: Connection timed out".
>>> After some
>>> > trial and error, I've managed to boot it. Here's what works right now:
>>> 1) Boot
>>> > into system rescue target with debug shell 2) start sssd 3) isolate
>>> graphical.target
>>> >
>>> > I have a replica which I haven't upgraded to 7.3 yet. So I can compare
>>> the two
>>> > systems to isolate the problem.
>>> >
>>>
>>> I'm afraid that without more info(messages/journal) nobody will be able
>>> to help.
>>>
>>> But based on the description it seems that it didn't even get to step
>>> where IPA is started.
>>>
>>> --
>>> Petr Vobornik
>>>
>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IDM server doesn't boot after update to RHEL 7.3

[Prasun Gera]

Yes, from my experiments, it gets stuck at some point where it has to start
avahi. And it fails to start it because it is dependent on something that
is not started yet (which is started when sssd is started). Googling for
that error pointed took me to
http://www.calculate-linux.org/boards/15/topics/26673, which seems to be
somewhat related I think. I'll post the journal messages soon. Is there
some sort of a systemd diff utility which can compare the start sequence of
services from two different systems ? Since my replica is on 7.2, which
afaik works fine, doing a diff between the two might highlight if something
has changed in the start sequence.

On Thu, Nov 10, 2016 at 12:35 PM, Petr Vobornik <pvobo...@redhat.com> wrote:

> On 11/09/2016 12:53 PM, Prasun Gera wrote:
> > It looks like something is messed up in the systemd configuration after
> 7.3. My
> > system doesn't boot at all. The boot screen would display the message:
> "Failed
> > to register match for Disconnected message: Connection timed out". After
> some
> > trial and error, I've managed to boot it. Here's what works right now:
> 1) Boot
> > into system rescue target with debug shell 2) start sssd 3) isolate
> graphical.target
> >
> > I have a replica which I haven't upgraded to 7.3 yet. So I can compare
> the two
> > systems to isolate the problem.
> >
>
> I'm afraid that without more info(messages/journal) nobody will be able
> to help.
>
> But based on the description it seems that it didn't even get to step
> where IPA is started.
>
> --
> Petr Vobornik
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] IDM server doesn't boot after update to RHEL 7.3

[Prasun Gera]

It looks like something is messed up in the systemd configuration after
7.3. My system doesn't boot at all. The boot screen would display the
message: "Failed to register match for Disconnected message: Connection
timed out". After some trial and error, I've managed to boot it. Here's
what works right now: 1) Boot into system rescue target with debug shell 2)
start sssd 3) isolate graphical.target

I have a replica which I haven't upgraded to 7.3 yet. So I can compare the
two systems to isolate the problem.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Package naming conflicts with update to RHEL 7.3

[Prasun Gera]

Thanks Martin. That bug report is private. I take it that it's not very
serious ?

On Mon, Nov 7, 2016 at 3:12 AM, Martin Babinsky <mbabi...@redhat.com> wrote:

> On 11/07/2016 01:31 AM, Prasun Gera wrote:
>
>> Getting this in yum check all after update to 7.3
>>
>> ipa-client-4.4.0-12.el7.x86_64 has installed conflicts freeipa-client:
>> ipa-client-4.4.0-12.el7.x86_64
>> ipa-client-common-4.4.0-12.el7.noarch has installed conflicts
>> freeipa-client-common: ipa-client-common-4.4.0-12.el7.noarch
>> ipa-common-4.4.0-12.el7.noarch has installed conflicts freeipa-common:
>> ipa-common-4.4.0-12.el7.noarch
>> ipa-python-compat-4.4.0-12.el7.noarch has installed conflicts
>> freeipa-python-compat: ipa-python-compat-4.4.0-12.el7.noarch
>>
>>
>>
>>
> Hi Prasun,
>
> That is a false positive caused by a bug in yum, see
> https://bugzilla.redhat.com/show_bug.cgi?id=1370134
>
> --
> Martin^3 Babinsky
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Package naming conflicts with update to RHEL 7.3

[Prasun Gera]

Getting this in yum check all after update to 7.3

ipa-client-4.4.0-12.el7.x86_64 has installed conflicts freeipa-client:
ipa-client-4.4.0-12.el7.x86_64
ipa-client-common-4.4.0-12.el7.noarch has installed conflicts
freeipa-client-common: ipa-client-common-4.4.0-12.el7.noarch
ipa-common-4.4.0-12.el7.noarch has installed conflicts freeipa-common:
ipa-common-4.4.0-12.el7.noarch
ipa-python-compat-4.4.0-12.el7.noarch has installed conflicts
freeipa-python-compat: ipa-python-compat-4.4.0-12.el7.noarch
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Do expired passwords remain usable indefinitely?

[Prasun Gera]

>
> There appears to be only one case where NAME_EXP is returned: when the
> client.expiration field is passed (not client.pw_expiration)
>
> I think "expiration" must equate to the "principal expiration" in IPA. But
> only regular password expiry would give you the option of changing it.
>
>
Thanks Brian. Can you explain a bit more ? When is principal expiration
triggered ? I haven't set it explicitly for any user, and ipa user-show
doesn't show that attribute either. I'm not very familiar with kerberos.
And as you and David said earlier, if the principal expires, kinit
shouldn't work either, right ?



> Regards,
>
> Brian.
>
> === from src/kdc/kdc_util. c ===
>
> /* The client must not be expired */
> if (client.expiration && client.expiration < kdc_time) {
> *status = "CLIENT EXPIRED";
> if (vague_errors)
> return(KRB_ERR_GENERIC);
> else
> return(KDC_ERR_NAME_EXP);
> }
>
> /* The client's password must not be expired, unless the server is
>a KRB5_KDC_PWCHANGE_SERVICE. */
> if (client.pw_expiration && client.pw_expiration < kdc_time &&
> !isflagset(server.attributes, KRB5_KDB_PWCHANGE_SERVICE)) {
> *status = "CLIENT KEY EXPIRED";
> if (vague_errors)
> return(KRB_ERR_GENERIC);
> else
> return(KDC_ERR_KEY_EXP);
> }
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Do expired passwords remain usable indefinitely?

[Prasun Gera]

David & Brian,
I'm familiar with the usual password expiration message that shows up which
forces you to change the password. I've seen that before. However, I didn't
see it this time, which is odd. Since I was able to kinit, I reset the
password, and it started working again. I don't have an account in this
failed state currently, but is it possible to force password expiration in
order to reproduce this again ? Something like "ipa user-mod myuser
--setattr=krbpasswordexpiration=" should work, right ?

On Tue, Oct 25, 2016 at 3:54 AM, Brian Candler <b.cand...@pobox.com> wrote:

> On 25/10/2016 00:02, Prasun Gera wrote:
>
> I've seen some different behaviour. I've had errors for users (including
> the admin user) trying to log in with possibly an expired password. Both
> webui and ssh would fail, but kinit would work. I'm not sure if this is
> related to the password's expiration or the account's expiration. My
> /var/log/secure has messages like "pam_sss(sshd:auth): received for user
> uname: 13 (User account has expired)". Is there a setting for default
> expiration of user accounts ? I don't remember setting it anywhere.
>
> By "account expiration" do you mean the "--principal-expiration" option to
> ipa user-xxx? Or is there another setting?
> Code 13 is PAM_ACCT_EXPIRED, at least in the "new" constants
>
> $ egrep '\b13\b' /usr/include/security/*pam*
> /usr/include/security/_pam_compat.h:# define PAM_USER_UNKNOWN
> 13
> /usr/include/security/_pam_types.h:#define PAM_ACCT_EXPIRED 13/* User
> account has expired */
> /usr/include/security/_pam_types.h:#define PAM_AUTHTOK_TYPE   13   /* The
> type for pam_get_authtok */
>
> This to me implies it's not looking at the krbPasswordExpiration
> attribute, because it could (or should) use PAM_AUTHTOK_EXPIRED (27) for
> that instead.
>
> For me, pam_sss seems to handle expiry correctly. For example if I reset
> an account password (which in turn causes it to expire immediately), and
> then someone logs in their ssh private key, and subsequently does "sudo",
> sudo prompts them for the password, tells them it has expired, but gives
> them the opportunity to change it.
>
> However it's not impossible that the PAM module has some buried logic,
> e.g. it refuses to use a password which expired more than X days ago. That
> was the reason for my original question.  I guess I should try setting some
> expiry date way in the past.
>
> The other thing is to look in the source code for pam_sss to see under
> which conditions it returns PAM_ACCT_EXPIRED.  The answer is: when it gets
> ERR_ACCOUNT_EXPIRED from parse_krb5_child_response. Which in turn is when
> we get KRB5KDC_ERR_NAME_EXP from Kerberos. Which in turn is "Client's entry
> in database has expired".
>
> http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-
> admin/Kerberos-V5-Library-Error-Codes.html
>
> But as has already been said - if the *principal* has expired you
> shouldn't be able to login with kinit at all.
>
> Regards,
>
> Brian.
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Do expired passwords remain usable indefinitely?

[Prasun Gera]

I've seen some different behaviour. I've had errors for users (including
the admin user) trying to log in with possibly an expired password. Both
webui and ssh would fail, but kinit would work. I'm not sure if this is
related to the password's expiration or the account's expiration. My
/var/log/secure has messages like "pam_sss(sshd:auth): received for user
uname: 13 (User account has expired)". Is there a setting for default
expiration of user accounts ? I don't remember setting it anywhere.

On Mon, Oct 24, 2016 at 8:13 AM, David Kupka  wrote:

> On 21/10/16 15:17, Brian Candler wrote:
>
>> Question: when a password expires, does it remain in a usable state in
>> the database indefinitely? For example, if someone comes along a year
>> after their password has expired, can they still login once with that
>> password?
>>
>> This is actually what I want, but I just want to confirm there's not
>> some sort of secondary threshold which means that an expired password is
>> not usable X days after it has expired.  Or, if there is such a
>> secondary threshold, where I can find it.
>>
>> The scenario is a RADIUS server for wifi which reads NTLM password
>> hashes out of the database to authenticate - this continues to work
>> after expiry. However I want users to be able to do a self-reset later
>> if and when they want to.
>>
>> Thanks,
>>
>> Brian.
>>
>>
> Hello Brian!
>
> AFAIK, it will work. Your RADIUS server will retrieve the hash from LDAP
> and do the validation locally. So FreeIPA has no way to say the password is
> expired.
> When the user tries to obtain Kerberos ticket he will be forced to change
> the password and NTLM hash will be also regenerated.
>
> --
> David Kupka
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SELinux errors with sssd-krb5-common-1.13.0-40.el7_2.12.x86_64

[Prasun Gera]

I need to set SELinux to enforcing to get the relevant SSSD logs, right ?

On Thu, Sep 29, 2016 at 3:42 AM, Sumit Bose <sb...@redhat.com> wrote:

> On Thu, Sep 29, 2016 at 12:47:34AM -0400, Prasun Gera wrote:
> > I started seeing some selinux errors on one of my RHEL 7 clients recently
> > (possibly after a recent yum update ?), which prevents users from logging
> > in with passwords. I've put SELinux in permissive mode for now. Logs
> follow
>
> This sounds like https://bugzilla.redhat.com/show_bug.cgi?id=1301686 .
> Would you mind adding your findings and the SSSD logs as described in
> https://bugzilla.redhat.com/show_bug.cgi?id=1301686#c2 to the bugzilla
> ticket.
>
> Thank you.
>
> bye,
> Sumit
>
> >
> >
> > SELinux is preventing /usr/libexec/sssd/krb5_child from read access on
> the
> > key Unknown.
> >
> > *  Plugin catchall (100. confidence) suggests
> > **
> >
> > If you believe that krb5_child should be allowed read access on the
> Unknown
> > key by default.
> > Then you should report this as a bug.
> > You can generate a local policy module to allow this access.
> > Do
> > allow this access for now by executing:
> > # grep krb5_child /var/log/audit/audit.log | audit2allow -M mypol
> > # semodule -i mypol.pp
> >
> >
> > Additional Information:
> > Source Contextsystem_u:system_r:sssd_t:s0
> > Target Contextsystem_u:system_r:unconfined_service_t:s0
> > Target ObjectsUnknown [ key ]
> > Sourcekrb5_child
> > Source Path   /usr/libexec/sssd/krb5_child
> > Port  
> > Host  
> > Source RPM Packages   sssd-krb5-common-1.13.0-40.el7_2.12.x86_64
> > Target RPM Packages
> > Policy RPMselinux-policy-3.13.1-60.el7_2.9.noarch
> > Selinux Enabled   True
> > Policy Type   targeted
> > Enforcing ModePermissive
> > Host Name example.com
> > Platform  Linux example.com 4.4.19-1.el7.x86_64
> >   #1 SMP Mon Aug 29 18:38:32 EDT 2016 x86_64
> > x86_64
> > Alert Count   38
> > First Seen2016-09-28 18:37:43 EDT
> > Last Seen 2016-09-28 22:08:41 EDT
> > Local ID  aa5271fa-f708-46b0-a382-fb1f90ce8973
> > Raw Audit Messages
> > type=AVC msg=audit(1475114921.376:90787): avc:  denied  { read } for
> >  pid=8272 comm="krb5_child" scontext=system_u:system_r:sssd_t:s0
> > tcontext=system_u:system_r:unconfined_service_t:s0 tclass=key
> permissive=0
> >
> >
> > type=SYSCALL msg=audit(1475114921.376:90787): arch=x86_64 syscall=keyctl
> > success=yes exit=EINTR a0=b a1=333b5463 a2=0 a3=0 items=0 ppid=891
> pid=8272
> > auid=4294967295 uid=1388200053 gid=1388200053 euid=1388200053
> > suid=1388200053 fsuid=1388200053 egid=1388200053 sgid=1388200053
> > fsgid=1388200053 tty=(none) ses=4294967295 comm=krb5_child
> > exe=/usr/libexec/sssd/krb5_child subj=system_u:system_r:sssd_t:s0
> key=(null)
> >
> > Hash: krb5_child,sssd_t,unconfined_service_t,key,read
> >
> > 
> 
> >
> > SELinux is preventing /usr/libexec/sssd/krb5_child from view access on
> the
> > key Unknown.
> >
> > *  Plugin catchall (100. confidence) suggests
> > **
> >
> > If you believe that krb5_child should be allowed view access on the
> Unknown
> > key by default.
> > Then you should report this as a bug.
> > You can generate a local policy module to allow this access.
> > Do
> > allow this access for now by executing:
> > # grep krb5_child /var/log/audit/audit.log | audit2allow -M mypol
> > # semodule -i mypol.pp
> >
> >
> > Additional Information:
> > Source Contextsystem_u:system_r:sssd_t:s0
> > Target Contextsystem_u:system_r:unconfined_service_t:s0
> > Target ObjectsUnknown [ key ]
> > Sourcekrb5_child
> > Source Path   /usr/libexec/sssd/krb5_child
> > Port  
> > Host  
> > Source RPM Packages   sssd-krb5-common-1.13.0-40.el7_2.12.x86_64
> > Target RPM Packages
> > Policy RPMselinux-policy-3.13.1-60.el7_2.9.noarch
> > Selinu

[Freeipa-users] SELinux errors with sssd-krb5-common-1.13.0-40.el7_2.12.x86_64

[Prasun Gera]

I started seeing some selinux errors on one of my RHEL 7 clients recently
(possibly after a recent yum update ?), which prevents users from logging
in with passwords. I've put SELinux in permissive mode for now. Logs follow


SELinux is preventing /usr/libexec/sssd/krb5_child from read access on the
key Unknown.

*  Plugin catchall (100. confidence) suggests
**

If you believe that krb5_child should be allowed read access on the Unknown
key by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep krb5_child /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Contextsystem_u:system_r:sssd_t:s0
Target Contextsystem_u:system_r:unconfined_service_t:s0
Target ObjectsUnknown [ key ]
Sourcekrb5_child
Source Path   /usr/libexec/sssd/krb5_child
Port  
Host  
Source RPM Packages   sssd-krb5-common-1.13.0-40.el7_2.12.x86_64
Target RPM Packages
Policy RPMselinux-policy-3.13.1-60.el7_2.9.noarch
Selinux Enabled   True
Policy Type   targeted
Enforcing ModePermissive
Host Name example.com
Platform  Linux example.com 4.4.19-1.el7.x86_64
  #1 SMP Mon Aug 29 18:38:32 EDT 2016 x86_64
x86_64
Alert Count   38
First Seen2016-09-28 18:37:43 EDT
Last Seen 2016-09-28 22:08:41 EDT
Local ID  aa5271fa-f708-46b0-a382-fb1f90ce8973
Raw Audit Messages
type=AVC msg=audit(1475114921.376:90787): avc:  denied  { read } for
 pid=8272 comm="krb5_child" scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:system_r:unconfined_service_t:s0 tclass=key permissive=0


type=SYSCALL msg=audit(1475114921.376:90787): arch=x86_64 syscall=keyctl
success=yes exit=EINTR a0=b a1=333b5463 a2=0 a3=0 items=0 ppid=891 pid=8272
auid=4294967295 uid=1388200053 gid=1388200053 euid=1388200053
suid=1388200053 fsuid=1388200053 egid=1388200053 sgid=1388200053
fsgid=1388200053 tty=(none) ses=4294967295 comm=krb5_child
exe=/usr/libexec/sssd/krb5_child subj=system_u:system_r:sssd_t:s0 key=(null)

Hash: krb5_child,sssd_t,unconfined_service_t,key,read



SELinux is preventing /usr/libexec/sssd/krb5_child from view access on the
key Unknown.

*  Plugin catchall (100. confidence) suggests
**

If you believe that krb5_child should be allowed view access on the Unknown
key by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep krb5_child /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Contextsystem_u:system_r:sssd_t:s0
Target Contextsystem_u:system_r:unconfined_service_t:s0
Target ObjectsUnknown [ key ]
Sourcekrb5_child
Source Path   /usr/libexec/sssd/krb5_child
Port  
Host  
Source RPM Packages   sssd-krb5-common-1.13.0-40.el7_2.12.x86_64
Target RPM Packages
Policy RPMselinux-policy-3.13.1-60.el7_2.9.noarch
Selinux Enabled   True
Policy Type   targeted
Enforcing ModePermissive
Host Name example.com
Platform  Linux example.com 4.4.19-1.el7.x86_64
  #1 SMP Mon Aug 29 18:38:32 EDT 2016 x86_64
x86_64
Alert Count   10
First Seen2016-09-28 18:40:00 EDT
Last Seen 2016-09-28 22:08:41 EDT
Local ID  22ec0970-9447-444a-9631-69749e4e7226
Raw Audit Messages
type=AVC msg=audit(1475114921.376:90789): avc:  denied  { view } for
 pid=8272 comm="krb5_child" scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:system_r:unconfined_service_t:s0 tclass=key permissive=0


type=SYSCALL msg=audit(1475114921.376:90789): arch=x86_64 syscall=keyctl
success=no exit=EACCES a0=6 a1=2e1c07f1 a2=0 a3=0 items=0 ppid=891 pid=8272
auid=4294967295 uid=1388200053 gid=1388200053 euid=1388200053
suid=1388200053 fsuid=1388200053 egid=1388200053 sgid=1388200053
fsgid=1388200053 tty=(none) ses=4294967295 comm=krb5_child
exe=/usr/libexec/sssd/krb5_child subj=system_u:system_r:sssd_t:s0 key=(null)

Hash: krb5_child,sssd_t,unconfined_service_t,key,view



SELinux is preventing /usr/libexec/sssd/krb5_child from write access on the
key Unknown.

*  Plugin catchall (100. confidence) suggests

Re: [Freeipa-users] ipa-client-automount --uninstall breaks central sudo on ipa-server

[Prasun Gera]

>
> In retrospect saving a copy of nsswitch.conf is a bit overkill. It really
> just needs to save and restore the automount entry in /etc/nsswitch.conf,
> not the whole file.
>
>
I think it should also remove the sssd configuration in addition to
removing it from nssswitch. i.e. Uninstalling the automount should bring
sssd to a clean state as well.


> rob
>
>
>> On Sat, Aug 27, 2016 at 1:49 AM, Mariusz Stolarczyk
>> <zeusu...@hotmail.com <mailto:zeusu...@hotmail.com>> wrote:
>>
>> The /etc/nsswitch.conf was the culprit. Fortunately there is a
>> /etc/nsswitch.cof.bak and that did the trick.
>>
>>
>> Rob, your suspicion was correct the sudoers line was missing.
>>
>>
>> It actually looks like the ipa-client-automount --uninstall reverts
>> the nsswitch.conf file to default pre-ipa values.
>>
>>
>> Still a bit curious that the ipa-client-automount
>> --location=server_mounts did not take on the ipa-server. If there is
>> a good reason for this behavior I would suggest that the
>> ipa-client-automount command would not even start it it was
>> executed on the ipa server.
>>
>>
>> thanks everyone!
>>
>> ms
>>
>> 
>> 
>> *From:* Prasun Gera <prasun.g...@gmail.com
>> <mailto:prasun.g...@gmail.com>>
>> *Sent:* Friday, August 26, 2016 4:02 PM
>> *To:* Rob Crittenden
>> *Cc:* m s; freeipa-users@redhat.com <mailto:freeipa-users@redhat.com>
>> *Subject:* Re: [Freeipa-users] ipa-client-automount --uninstall
>> breaks central sudo on ipa-server
>> ipa-client-automount --uninstall was(is?) a bit broken in that it
>> tries to revert back to an older configuration, but it can
>> accidentally revert it to a state before the ipa-client was
>> installed (as opposed to the state where automount was installed).
>> Check your nssswitch.conf file and compare it to other clients on
>> which things work fine. You might notice differences.
>>
>> On Fri, Aug 26, 2016 at 11:35 AM, Rob Crittenden
>> <rcrit...@redhat.com <mailto:rcrit...@redhat.com>> wrote:
>>
>> m s wrote:
>>
>> Need help restoring central sudo rights on ipa server.
>>
>>
>> How I broke it!!!: I decided to take advantage of the
>> centralized
>> automount feature with a custom location for a couple
>> mounts. When I ran
>> the ipa-client-automount --location=server_mounts it
>> appeared to install
>> correctly but that didn't appear not to work so my plan was
>> to manually
>> setup the automount since it is only one machine. So of
>> course I ran the
>> ipa-client-automount --uninstall on the ipa server and thats
>> when I lost
>> the sudo rights on the ipa server: superuser not in the
>> sudoers file,
>> this incident will be reported.
>>
>>
>> I have repeated this steps with the same results:
>>
>> Initially sudo works for superuser
>>
>> And after ipa-client-automount --location=server_mounts (on
>> the ipa-server)
>>
>> sudo still works
>>
>> but after, ipa-client-automount --uninstall
>>
>> no sudo for superuser on the ipa server but the superuser
>> still has sudo
>> privilages on the clients
>>
>>
>> background/versions:
>>
>> My setup is all CentOS 7.2 machines with one ipa server and
>> the rest are
>> clients all using ipa version 4.2.0.
>>
>> I had no issues using the ipa-client-automount on all my
>> clients to
>> configure network homes and shares as well as setting up a
>> superuser
>> with central sudo powers before this happened.
>>
>>
>> 1.) Don't be too harsh if it is a BIG NO-NO to run the
>> ipa-client-automount command on the ipa-server
>>
>> 2.) Not sure what logs or config files i need to post.
>>
>>
>> I'd confirm that sssd is still configured to do sudo by looking
>> for sss in the sudoers line in /etc/nssswitch.conf and ensure
>> that sudo is an enabled service in /etc/sssd/sssd.conf, probably
>> something like:
>>
>> services = nss, sudo, pam, ssh
>>
>> rob
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> <https://www.redhat.com/mailman/listinfo/freeipa-users>
>> Go to http://freeipa.org for more info on the project
>>
>>
>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-automount --uninstall breaks central sudo on ipa-server

[Prasun Gera]

I had created a bug for this
https://bugzilla.redhat.com/show_bug.cgi?id=1276153, and there was an
existing bug report too (https://bugzilla.redhat.com/show_bug.cgi?id=1141799),
but that's been marked as wontfix. Since this trips multiple people, I
would like to propose reopening it.

On Sat, Aug 27, 2016 at 1:49 AM, Mariusz Stolarczyk <zeusu...@hotmail.com>
wrote:

> The /etc/nsswitch.conf was the culprit. Fortunately there is a
> /etc/nsswitch.cof.bak and that did the trick.
>
>
> Rob, your suspicion was correct the sudoers line was missing.
>
>
> It actually looks like the ipa-client-automount --uninstall reverts the
> nsswitch.conf file to default pre-ipa values.
>
>
> Still a bit curious that the ipa-client-automount --location=server_mounts
> did not take on the ipa-server. If there is a good reason for this behavior
> I would suggest that the ipa-client-automount command would not even
> start it it was executed on the ipa server.
>
>
> thanks everyone!
> ms
>
> --
> *From:* Prasun Gera <prasun.g...@gmail.com>
> *Sent:* Friday, August 26, 2016 4:02 PM
> *To:* Rob Crittenden
> *Cc:* m s; freeipa-users@redhat.com
> *Subject:* Re: [Freeipa-users] ipa-client-automount --uninstall breaks
> central sudo on ipa-server
>
> ipa-client-automount --uninstall was(is?) a bit broken in that it tries to
> revert back to an older configuration, but it can accidentally revert it to
> a state before the ipa-client was installed (as opposed to the state where
> automount was installed). Check your nssswitch.conf file and compare it to
> other clients on which things work fine. You might notice differences.
>
> On Fri, Aug 26, 2016 at 11:35 AM, Rob Crittenden <rcrit...@redhat.com>
> wrote:
>
>> m s wrote:
>>
>>> Need help restoring central sudo rights on ipa server.
>>>
>>>
>>> How I broke it!!!: I decided to take advantage of the centralized
>>> automount feature with a custom location for a couple mounts. When I ran
>>> the ipa-client-automount --location=server_mounts it appeared to install
>>> correctly but that didn't appear not to work so my plan was to manually
>>> setup the automount since it is only one machine. So of course I ran the
>>> ipa-client-automount --uninstall on the ipa server and thats when I lost
>>> the sudo rights on the ipa server: superuser not in the sudoers file,
>>> this incident will be reported.
>>>
>>>
>>> I have repeated this steps with the same results:
>>>
>>> Initially sudo works for superuser
>>>
>>> And after ipa-client-automount --location=server_mounts (on the
>>> ipa-server)
>>>
>>> sudo still works
>>>
>>> but after, ipa-client-automount --uninstall
>>>
>>> no sudo for superuser on the ipa server but the superuser still has sudo
>>> privilages on the clients
>>>
>>>
>>> background/versions:
>>>
>>> My setup is all CentOS 7.2 machines with one ipa server and the rest are
>>> clients all using ipa version 4.2.0.
>>>
>>> I had no issues using the ipa-client-automount on all my clients to
>>> configure network homes and shares as well as setting up a superuser
>>> with central sudo powers before this happened.
>>>
>>>
>>> 1.) Don't be too harsh if it is a BIG NO-NO to run the
>>> ipa-client-automount command on the ipa-server
>>>
>>> 2.) Not sure what logs or config files i need to post.
>>>
>>
>> I'd confirm that sssd is still configured to do sudo by looking for sss
>> in the sudoers line in /etc/nssswitch.conf and ensure that sudo is an
>> enabled service in /etc/sssd/sssd.conf, probably something like:
>>
>> services = nss, sudo, pam, ssh
>>
>> rob
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-client-automount --uninstall breaks central sudo on ipa-server

[Prasun Gera]

ipa-client-automount --uninstall was(is?) a bit broken in that it tries to
revert back to an older configuration, but it can accidentally revert it to
a state before the ipa-client was installed (as opposed to the state where
automount was installed). Check your nssswitch.conf file and compare it to
other clients on which things work fine. You might notice differences.

On Fri, Aug 26, 2016 at 11:35 AM, Rob Crittenden 
wrote:

> Mariusz Stolarczyk wrote:
>
>> Need help restoring central sudo rights on ipa server.
>>
>>
>> How I broke it!!!: I decided to take advantage of the centralized
>> automount feature with a custom location for a couple mounts. When I ran
>> the ipa-client-automount --location=server_mounts it appeared to install
>> correctly but that didn't appear not to work so my plan was to manually
>> setup the automount since it is only one machine. So of course I ran the
>> ipa-client-automount --uninstall on the ipa server and thats when I lost
>> the sudo rights on the ipa server: superuser not in the sudoers file,
>> this incident will be reported.
>>
>>
>> I have repeated this steps with the same results:
>>
>> Initially sudo works for superuser
>>
>> And after ipa-client-automount --location=server_mounts (on the
>> ipa-server)
>>
>> sudo still works
>>
>> but after, ipa-client-automount --uninstall
>>
>> no sudo for superuser on the ipa server but the superuser still has sudo
>> privilages on the clients
>>
>>
>> background/versions:
>>
>> My setup is all CentOS 7.2 machines with one ipa server and the rest are
>> clients all using ipa version 4.2.0.
>>
>> I had no issues using the ipa-client-automount on all my clients to
>> configure network homes and shares as well as setting up a superuser
>> with central sudo powers before this happened.
>>
>>
>> 1.) Don't be too harsh if it is a BIG NO-NO to run the
>> ipa-client-automount command on the ipa-server
>>
>> 2.) Not sure what logs or config files i need to post.
>>
>
> I'd confirm that sssd is still configured to do sudo by looking for sss in
> the sudoers line in /etc/nssswitch.conf and ensure that sudo is an enabled
> service in /etc/sssd/sssd.conf, probably something like:
>
> services = nss, sudo, pam, ssh
>
> rob
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Please Provide the IPA Client Configuration Doc for Ubuntu 12.04, 14.04

[Prasun Gera]

Ubuntu 12.04 won't work very well out of the box. You can get it to work
with the freeipa and sssd ppas, but you'll still need some small hacks on
top of it. 14.04 is much better, and 16.04 is presumably the best in terms
of things working out of the box.

On Fri, Jul 15, 2016 at 3:59 AM, Jakub Hrozek  wrote:

> On Fri, Jul 15, 2016 at 11:41:03AM +0530, Visakh MV wrote:
> > Hi Team,
> >
> > I forgot to describe the actual requirement on IPA client machines, which
> > we needs to configure client machine SUDO privilege from FreeIPA server
> for
> > IPA Server users. after configuring client machines can able to login as
> a
> > IPA user but unable to give sudo privilege from.  Please revert back your
> > kind response
>
> We don't have any special Ubuntu guide, the client setup should be the
> same as on RHEL though, just ipa-client-install.
>
> About sudo, I don't know what sssd version there is on Ubuntu 12, but
> if it's an old version (<1.9) you might need to configure
> sudo_provider=ldap. With more recent versions, sudo_provider=ipa is
> already included.
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Replace with 3rd part certificates

[Prasun Gera]

There were issues with 3rd party certs as of RHEL 7.2/4.2. If this is fixed
in 7.3, that would be great, especially for Lets Encrypt certs (even
without auto-renewal)

On Fri, Jul 1, 2016 at 5:15 AM, Andreas Ladanyi 
wrote:

> Hi,
> > For the time being and as far as I can see until IPA 4.3.1, the
> procedure is messy and difficult.
> > The following thread will be a big help:
> > https://www.redhat.com/archives/freeipa-users/2016-January/msg00223.html
> >
> > I think I succeeded at last, but further tests remain.
> Is it possible to backport the working procedure from 4.3.1 to 4.2 in
> Fedora 23 ?
> >
> >
> regards,
> Andreas
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] What causes the web ui to display a second login dialog ?

[Prasun Gera]

Thanks. I'll wait for RHEL 7.3 then.

On Thu, Jun 23, 2016 at 4:27 PM, Simo Sorce <s...@redhat.com> wrote:

> On Thu, 2016-06-23 at 14:11 -0400, Prasun Gera wrote:
> > Image attached. I don't use Windows much, but I noticed this on a windows
> > machine with Chrome. Before the actual login page is displayed, this
> login
> > dialog is displayed. Further, the credentials don't work in this dialog.
> >
> > Env: RHEL 7.2, idm 4.x
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
>
> We have some workarounds available in latest mod_auth_gssapi, they
> should land in RHEL7.3 and hopefully make it easier to deal with this
> problem.
> https://fedorahosted.org/freeipa/ticket/5614
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] question about automount config

[Prasun Gera]

ome/afayzullin on /mnt type nfs4
> (rw,relatime,seclabel,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=10.254.1.168,local_lock=none,addr=10.254.1.167)
>
> $ ssh nfsclient
> Creating home directory for afayzullin.
> Last login: Tue Jun  7 17:34:14 2016
> Could not chdir to home directory /home/afayzullin: No such file or
> directory
> -bash-4.3$ ll /mnt
> итого 0
> -rw-rw-r--. 1 afayzullin afayzullin 0 июн  7 17:00 test
>
> but home is empty
> # ll /home/
> итого 0
>
> So what steps should I take next?
>
> 24.05.2016 18:01, Prasun Gera пишет:
>
> You can stop the autofs daemon, and run it in foreground with automount
> -fvv. Then try to access the mount point in parallel. The logs from the
> foreground run should shed some light. Also, does your autofs setup work
> without kerberos ? As a first step it to work with non-kerberised nfs.
>
> On Mon, May 23, 2016 at 11:06 AM, Arthur Fayzullin < <art...@deus.pro>
> art...@deus.pro> wrote:
>
>> Good day, colleagues!
>> I am confused about how automount work and howto configure it. I have
>> tried to configure it according to
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html
>> document (paragraph 9.1.1 and chapter 20).
>> I have tried to make it work on 3 servers:
>> 1. ipa server;
>> 2. nfs server (node00);
>> 3. nfs client (postgres).
>>
>>
>> *** so here how it configured on ipa server:
>> $ ipa automountlocation-tofiles amantai
>> /etc/auto.master:
>> /-  /etc/auto.direct
>> /home   /etc/auto.home
>> ---
>> /etc/auto.direct:
>> ---
>> /etc/auto.home:
>> *   -sec=kr5i,rw,fstype=nfs4 node00.glavsn.ab:/home/&
>>
>> maps not connected to /etc/auto.master:
>>
>> $ ipa service-find nfs
>> --
>> 2 services matched
>> --
>>   Основной: nfs/node00.glavsn...@glavsn.ab
>>   Keytab: True
>>   Managed by: node00.glavsn.ab
>>
>>   Основной: nfs/postgres.glavsn...@glavsn.ab
>>   Keytab: True
>>   Managed by: postgres.glavsn.ab
>>
>>
>> *** here is nfs server config:
>> $ sudo klist -k
>> Пароль:
>> Keytab name: FILE:/etc/krb5.keytab
>> KVNO Principal
>> 
>> --
>>1 host/node00.glavsn...@glavsn.ab
>>1 host/node00.glavsn...@glavsn.ab
>>1 host/node00.glavsn...@glavsn.ab
>>1 host/node00.glavsn...@glavsn.ab
>>2 nfs/node00.glavsn...@glavsn.ab
>>2 nfs/node00.glavsn...@glavsn.ab
>>2 nfs/node00.glavsn...@glavsn.ab
>>2 nfs/node00.glavsn...@glavsn.ab
>>
>> $ cat /etc/exports
>> /home *(rw,sec=sys:krb5:krb5i:krb5p)
>>
>> $ sudo firewall-cmd --list-all
>> public (default, active)
>>   interfaces: bridge0 enp1s0
>>   sources:
>>   services: dhcpv6-client nfs ssh
>>   ports: 8001/tcp
>>   masquerade: no
>>   forward-ports:
>>   icmp-blocks:
>>   rich rules:
>>
>> $ getenforce
>> Enforcing
>>
>>
>> *** here nfs client config:
>> # klist -k
>> Keytab name: FILE:/etc/krb5.keytab
>> KVNO Principal
>> 
>> --
>>1 host/postgres.glavsn...@glavsn.ab
>>1 host/postgres.glavsn...@glavsn.ab
>>1 host/postgres.glavsn...@glavsn.ab
>>1 host/postgres.glavsn...@glavsn.ab
>>1 nfs/postgres.glavsn...@glavsn.ab
>>1 nfs/postgres.glavsn...@glavsn.ab
>>1 nfs/postgres.glavsn...@glavsn.ab
>>1 nfs/postgres.glavsn...@glavsn.ab
>>
>> # firewall-cmd --list-all
>> FedoraServer (default, active)
>>   interfaces: ens3
>>   sources:
>>   services: cockpit dhcpv6-client ssh
>>   ports:
>>   protocols:
>>   masquerade: no
>>   forward-ports:
>>   icmp-blocks:
>>   rich rules:
>>
>> # mount -l  (contains next string)
>> auto.home on /home type autofs
>> (rw,relatime,fd=25,pgrp=960,timeout=300,minproto=5,maxproto=5,indirect)
>>
>> # ll /home/afayzullin
>> ls says that it cannot access /home/afayzullin: no such file or directory
>>
>> I have run
>> # ipa-client-automount --location=amantai
>> on client and it has completed successfully.
>>
>> I have tried to disable selinux, drop iptables rules. And now I am
>> little confused about what to do next. May if someone has faced with
>> automount config can give me some advice, or if there is any howto
>> config automount, or some can advise howto debug this situation?
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>
>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] OCSP and CRL in certs for java firefox plugin

[Prasun Gera]

>
>
> To summarize, your options seem to be:
> * Create ipa-ca DNS record in your primary domain
> * Update the main default certificate profile (present in FreeIPA 4.2+)
> * Migrate whole FreeIPA deployment to other DNS primary you would control
> (pqr.xyz.com) - which is a lot of work but may unblock you in future if
> you
> want to start the mentioned AD trusts.
>
> Martin
>

Thanks Martin for the suggestions. In the short term, updating the external
will probably not work. Eventually, migration to a domain that I can
control will be a better idea, but that will involve a lot more work. Is
there any documentation on doing the migration ? My deployment is actually
fairly simple right now. We just use it internally for our small lab,
mostly as a replacement for NIS. No AD or windows machines. Hence, I didn't
bother with a lot of complex dns stuff to begin with. I guess, the only
thing we need to preserve is usernames, groups and passwords in the
migration.

Regarding your second point, how do I go about updating the cert profile ?
Is there any documentation ? If this is not a standard feature, do you
think I should open an RFE ?

Also, I'm surprised that nothing broke yet despite the OCSP/CRL stuff not
working ever. Isn't this important security-wise? Yet, browsers don't seem
to complain by default for https certs once the CA is trusted. Only the
java plugin brought this to my attention.



>
> > On Fri, May 27, 2016 at 10:19 PM, Rob Crittenden <rcrit...@redhat.com
> > <mailto:rcrit...@redhat.com>> wrote:
> >
> > Prasun Gera wrote:
> >
> > I've identified the problem. The uris seem to be incorrect. This
> looks
> > like some substitution gone wrong. Instead of using the actual
> ipa
> > server's address, it points to a generic placeholder type text
> > (ipa-ca.domain.com <http://ipa-ca.domain.com>
> > <http://ipa-ca.domain.com>). Relevant part of the
> > certificate:
> >
> >
> > A generic name is used in case the server that issued the cert goes
> away.
> > Create an entry in DNS for this generic name and things should work
> as expected.
> >
> > rob
> >
> >
> > Authority Information Access:
> >   OCSP - URI:*http://ipa-ca.domain.com/ca/ocsp*
> >
> >   X509v3 Key Usage: critical
> >   Digital Signature, Non Repudiation, Key
> Encipherment,
> > Data Encipherment
> >   X509v3 Extended Key Usage:
> >   TLS Web Server Authentication, TLS Web Client
> > Authentication
> >   X509v3 CRL Distribution Points:
> >
> >   Full Name:
> > URI:*
> http://ipa-ca.domain.com/ipa/crl/MasterCRL.bin*
> >
> >
> > This is on RHEL 7.2, idm 4.2 btw
> >
> > On Fri, May 27, 2016 at 7:22 PM, Prasun Gera <
> prasun.g...@gmail.com
> > <mailto:prasun.g...@gmail.com>
> > <mailto:prasun.g...@gmail.com <mailto:prasun.g...@gmail.com>>>
> wrote:
> >
> >  It looks like that issue was fixed and the OCSP and CRL
> uris in the
> >  certs are now http. So I'm not sure why java is complaining.
> >
> >  On Fri, May 27, 2016 at 7:03 PM, Prasun Gera <
> prasun.g...@gmail.com
> > <mailto:prasun.g...@gmail.com>
> >  <mailto:prasun.g...@gmail.com <mailto:prasun.g...@gmail.com>>>
> wrote:
> >
> >  I've set up a couple of dell idrac card's ssl certs
> signed by
> >  ipa CA. I've also added the ipa CA to java's trusted
> CAs.
> >  However, when you try to launch the idrac java console,
> it will
> >  still show an error that the site is untrusted. Upon
> clicking on
> >  "more information", the message says that although the
> cert is
> >  signed by the CA, it cannot verify the revocation
> status. I
> >  found this page
> > http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs ,
> >  which explains potential problems with this since the
> main ipa
> >  server itself is also using an ssl cert signed by the
> ipa CA. So
> >  the client cannot verify the revocation if it can't
> reach the
> >  CA. Is there any solution to this ? Anyone tried this
> with idrac
> >  cards ?
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] OCSP and CRL in certs for java firefox plugin

[Prasun Gera]

The problem is that I'm not using ipa for dns. dns is handled externally,
and I don't have admin access. I have 1 master and 1 replica, and all the
clients are enrolled with --server=a,--server=b during installation, and I
think it works perfectly fine. Is it possible to instruct ipa to use some
alternative for the certs ? If it's not possible to list multiple uris,
even just the master would be fine. It would at least work when the master
is up, which it doesn't right now.

Secondly, I'm a bit confused regarding the dns too. This error is on a
client system like my laptop, which is an entirely unrelated system from
the ipa clients. The connection is over the internet. So the dns mapping
would have to be visible globally for my laptop to see it. However, the
name of the ipa domain is not the same the same as the name of domain in
the server addresses. (This was for some historic reason in NIS, and I
didn't change the domain name during migration). So what ipa is suggesting
is something like ipa-ca.abc.com, whereas all my servers are like
server1.pqr.xyz.com. I don't think it is anyway possible to do this right
now since I don't control abc.com.


On Fri, May 27, 2016 at 10:19 PM, Rob Crittenden <rcrit...@redhat.com>
wrote:

> Prasun Gera wrote:
>
>> I've identified the problem. The uris seem to be incorrect. This looks
>> like some substitution gone wrong. Instead of using the actual ipa
>> server's address, it points to a generic placeholder type text
>> (ipa-ca.domain.com <http://ipa-ca.domain.com>). Relevant part of the
>> certificate:
>>
>
> A generic name is used in case the server that issued the cert goes away.
> Create an entry in DNS for this generic name and things should work as
> expected.
>
> rob
>
>
>> Authority Information Access:
>>  OCSP - URI:*http://ipa-ca.domain.com/ca/ocsp*
>>
>>  X509v3 Key Usage: critical
>>  Digital Signature, Non Repudiation, Key Encipherment,
>> Data Encipherment
>>  X509v3 Extended Key Usage:
>>  TLS Web Server Authentication, TLS Web Client
>> Authentication
>>  X509v3 CRL Distribution Points:
>>
>>  Full Name:
>>    URI:*http://ipa-ca.domain.com/ipa/crl/MasterCRL.bin*
>>
>>
>> This is on RHEL 7.2, idm 4.2 btw
>>
>> On Fri, May 27, 2016 at 7:22 PM, Prasun Gera <prasun.g...@gmail.com
>> <mailto:prasun.g...@gmail.com>> wrote:
>>
>> It looks like that issue was fixed and the OCSP and CRL uris in the
>> certs are now http. So I'm not sure why java is complaining.
>>
>> On Fri, May 27, 2016 at 7:03 PM, Prasun Gera <prasun.g...@gmail.com
>> <mailto:prasun.g...@gmail.com>> wrote:
>>
>> I've set up a couple of dell idrac card's ssl certs signed by
>> ipa CA. I've also added the ipa CA to java's trusted CAs.
>> However, when you try to launch the idrac java console, it will
>> still show an error that the site is untrusted. Upon clicking on
>> "more information", the message says that although the cert is
>> signed by the CA, it cannot verify the revocation status. I
>> found this page
>> http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs ,
>> which explains potential problems with this since the main ipa
>> server itself is also using an ssl cert signed by the ipa CA. So
>> the client cannot verify the revocation if it can't reach the
>> CA. Is there any solution to this ? Anyone tried this with idrac
>> cards ?
>>
>>
>>
>>
>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] OCSP and CRL in certs for java firefox plugin

[Prasun Gera]

I've identified the problem. The uris seem to be incorrect. This looks like
some substitution gone wrong. Instead of using the actual ipa server's
address, it points to a generic placeholder type text (ipa-ca.domain.com).
Relevant part of the certificate:

Authority Information Access:
OCSP - URI:*http://ipa-ca.domain.com/ca/ocsp
<http://ipa-ca.domain.com/ca/ocsp>*

X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Data
Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:

Full Name:
  URI:*http://ipa-ca.domain.com/ipa/crl/MasterCRL.bin
<http://ipa-ca.domain.com/ipa/crl/MasterCRL.bin>*


This is on RHEL 7.2, idm 4.2 btw

On Fri, May 27, 2016 at 7:22 PM, Prasun Gera <prasun.g...@gmail.com> wrote:

> It looks like that issue was fixed and the OCSP and CRL uris in the certs
> are now http. So I'm not sure why java is complaining.
>
> On Fri, May 27, 2016 at 7:03 PM, Prasun Gera <prasun.g...@gmail.com>
> wrote:
>
>> I've set up a couple of dell idrac card's ssl certs signed by ipa CA.
>> I've also added the ipa CA to java's trusted CAs. However, when you try to
>> launch the idrac java console, it will still show an error that the site is
>> untrusted. Upon clicking on "more information", the message says that
>> although the cert is signed by the CA, it cannot verify the revocation
>> status. I found this page
>> http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs , which
>> explains potential problems with this since the main ipa server itself is
>> also using an ssl cert signed by the ipa CA. So the client cannot verify
>> the revocation if it can't reach the CA. Is there any solution to this ?
>> Anyone tried this with idrac cards ?
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] OCSP and CRL in certs for java firefox plugin

[Prasun Gera]

It looks like that issue was fixed and the OCSP and CRL uris in the certs
are now http. So I'm not sure why java is complaining.

On Fri, May 27, 2016 at 7:03 PM, Prasun Gera <prasun.g...@gmail.com> wrote:

> I've set up a couple of dell idrac card's ssl certs signed by ipa CA. I've
> also added the ipa CA to java's trusted CAs. However, when you try to
> launch the idrac java console, it will still show an error that the site is
> untrusted. Upon clicking on "more information", the message says that
> although the cert is signed by the CA, it cannot verify the revocation
> status. I found this page
> http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs , which
> explains potential problems with this since the main ipa server itself is
> also using an ssl cert signed by the ipa CA. So the client cannot verify
> the revocation if it can't reach the CA. Is there any solution to this ?
> Anyone tried this with idrac cards ?
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] OCSP and CRL in certs for java firefox plugin

[Prasun Gera]

I've set up a couple of dell idrac card's ssl certs signed by ipa CA. I've
also added the ipa CA to java's trusted CAs. However, when you try to
launch the idrac java console, it will still show an error that the site is
untrusted. Upon clicking on "more information", the message says that
although the cert is signed by the CA, it cannot verify the revocation
status. I found this page
http://www.freeipa.org/page/V3/Single_OCSP_and_CRL_in_certs , which
explains potential problems with this since the main ipa server itself is
also using an ssl cert signed by the ipa CA. So the client cannot verify
the revocation if it can't reach the CA. Is there any solution to this ?
Anyone tried this with idrac cards ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] question about automount config

[Prasun Gera]

You can stop the autofs daemon, and run it in foreground with automount
-fvv. Then try to access the mount point in parallel. The logs from the
foreground run should shed some light. Also, does your autofs setup work
without kerberos ? As a first step it to work with non-kerberised nfs.

On Mon, May 23, 2016 at 11:06 AM, Arthur Fayzullin  wrote:

> Good day, colleagues!
> I am confused about how automount work and howto configure it. I have
> tried to configure it according to
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html
> document (paragraph 9.1.1 and chapter 20).
> I have tried to make it work on 3 servers:
> 1. ipa server;
> 2. nfs server (node00);
> 3. nfs client (postgres).
>
>
> *** so here how it configured on ipa server:
> $ ipa automountlocation-tofiles amantai
> /etc/auto.master:
> /-  /etc/auto.direct
> /home   /etc/auto.home
> ---
> /etc/auto.direct:
> ---
> /etc/auto.home:
> *   -sec=kr5i,rw,fstype=nfs4 node00.glavsn.ab:/home/&
>
> maps not connected to /etc/auto.master:
>
> $ ipa service-find nfs
> --
> 2 services matched
> --
>   Основной: nfs/node00.glavsn...@glavsn.ab
>   Keytab: True
>   Managed by: node00.glavsn.ab
>
>   Основной: nfs/postgres.glavsn...@glavsn.ab
>   Keytab: True
>   Managed by: postgres.glavsn.ab
>
>
> *** here is nfs server config:
> $ sudo klist -k
> Пароль:
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> 
> --
>1 host/node00.glavsn...@glavsn.ab
>1 host/node00.glavsn...@glavsn.ab
>1 host/node00.glavsn...@glavsn.ab
>1 host/node00.glavsn...@glavsn.ab
>2 nfs/node00.glavsn...@glavsn.ab
>2 nfs/node00.glavsn...@glavsn.ab
>2 nfs/node00.glavsn...@glavsn.ab
>2 nfs/node00.glavsn...@glavsn.ab
>
> $ cat /etc/exports
> /home *(rw,sec=sys:krb5:krb5i:krb5p)
>
> $ sudo firewall-cmd --list-all
> public (default, active)
>   interfaces: bridge0 enp1s0
>   sources:
>   services: dhcpv6-client nfs ssh
>   ports: 8001/tcp
>   masquerade: no
>   forward-ports:
>   icmp-blocks:
>   rich rules:
>
> $ getenforce
> Enforcing
>
>
> *** here nfs client config:
> # klist -k
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> 
> --
>1 host/postgres.glavsn...@glavsn.ab
>1 host/postgres.glavsn...@glavsn.ab
>1 host/postgres.glavsn...@glavsn.ab
>1 host/postgres.glavsn...@glavsn.ab
>1 nfs/postgres.glavsn...@glavsn.ab
>1 nfs/postgres.glavsn...@glavsn.ab
>1 nfs/postgres.glavsn...@glavsn.ab
>1 nfs/postgres.glavsn...@glavsn.ab
>
> # firewall-cmd --list-all
> FedoraServer (default, active)
>   interfaces: ens3
>   sources:
>   services: cockpit dhcpv6-client ssh
>   ports:
>   protocols:
>   masquerade: no
>   forward-ports:
>   icmp-blocks:
>   rich rules:
>
> # mount -l  (contains next string)
> auto.home on /home type autofs
> (rw,relatime,fd=25,pgrp=960,timeout=300,minproto=5,maxproto=5,indirect)
>
> # ll /home/afayzullin
> ls says that it cannot access /home/afayzullin: no such file or directory
>
> I have run
> # ipa-client-automount --location=amantai
> on client and it has completed successfully.
>
> I have tried to disable selinux, drop iptables rules. And now I am
> little confused about what to do next. May if someone has faced with
> automount config can give me some advice, or if there is any howto
> config automount, or some can advise howto debug this situation?
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] How to determine cause/source of user lockout?

[Prasun Gera]

If it's the admin account, there would be a pretty good likelihood of
bruteforce attempts if your server is on the internet. One option is to
rename it to something else.
On 17 May 2016 11:36 a.m., "Rich Megginson"  wrote:

> On 05/17/2016 08:18 AM, Rob Crittenden wrote:
>
>> John Duino wrote:
>>
>>> Is there a (relatively easy) way to determine what is causing a user
>>> account to be locked out? The admin account on our 'primary' ipa host is
>>> locked out frequently, but somewhat randomly; sometimes it will be less
>>> than 5 minutes it is available, and other times several hours.
>>>
>>> ipa user-status admin will show something like:
>>> Failed logins: 6
>>> Last successful authentication: 20160516214142Z
>>> Last failed authentication: 20160516224718Z
>>> Time now: 2016-05-16T22:52:00Z
>>>
>>> ipa user-unlock admin  does unlock it.
>>>
>>> But parsing through the various logs on the affected host doesn't give
>>> me what I need to know, primarily, which host(s) are trying to access
>>> admin and causing it to lock.
>>>
>>> FreeIPA 4.2.0 on CentOS 7.2.1511
>>>
>>
>> I think you'd need to poke around in the KDC and 389-ds access log to
>> find the auth attempts. I guess I'd look for PREAUTH_FAILED in
>> /var/log/krb5kdc.log and look for err=49 in the 389-ds logs and then
>> correlate the conn value with a BIND to see who was authenticating.
>>
>
> For 389 you can use the logconv.pl tool
>
>
>> rob
>>
>>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] krb5kdc service not starting

[Prasun Gera]

I]: LDAP error -2
(Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure.  Minor code may provide more information (No Kerberos credentials
available)) errno 0 (Success)
[11/May/2016:23:19:52 -0400] slapi_ldap_bind - Error: could not perform
interactive bind for id [] authentication mechanism [GSSAPI]: error -2
(Local error)
[11/May/2016:23:19:52 -0400] NSMMReplicationPlugin - agmt="cn=
meToidm_master.cc.gt.atl.ga.us" (idm_master:389): Replication bind with
GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure:
GSSAPI Error: Unspecified GSS failure.  Minor code may provide more
information (No Kerberos credentials available))
[11/May/2016:23:19:52 -0400] NSMMReplicationPlugin -
agmt="cn=cloneAgreement1-idm_replica.com-pki-tomcat" (idm_master:389):
Unable to acquire replica: the replica instructed us to go into backoff
mode. Will retry later.
[11/May/2016:23:19:52 -0400] DSRetroclPlugin - delete_changerecord: could
not delete change record 404054 (rc: 32)
[11/May/2016:23:19:52 -0400] - slapd started.  Listening on All Interfaces
port 389 for LDAP requests
[11/May/2016:23:19:52 -0400] - Listening on All Interfaces port 636 for
LDAPS requests
[11/May/2016:23:19:52 -0400] - Listening on
/var/run/slapd-DOMAINNAME-EDU.socket for LDAPI requests
[11/May/2016:23:19:52 -0400] DSRetroclPlugin - delete_changerecord: could
not delete change record 404055 (rc: 32)
[11/May/2016:23:19:52 -0400] DSRetroclPlugin - delete_changerecord: could
not delete change record 404056 (rc: 32)
[11/May/2016:23:19:52 -0400] DSRetroclPlugin - delete_changerecord: could
not delete change record 404057 (rc: 32)
[11/May/2016:23:19:52 -0400] DSRetroclPlugin - delete_changerecord: could
not delete change record 404058 (rc: 32)
... lots of similar messages



On Thu, May 12, 2016 at 4:25 AM, Ludwig Krispenz <lkris...@redhat.com>
wrote:

>
> On 05/12/2016 05:28 AM, Prasun Gera wrote:
>
> Hi everyone,
> I had a pretty similar failure on my replica yesterday. The replica was
> not reachable, and I asked someone to have a look at the system. They
> presumably rebooted it. When it came back up, ipactl wouldn't start, and
> the symptoms were pretty similar to those described in this thread. I
> followed the solution of copying dse.ldif.startOK to dse.ldif, and that
> started everything.
>
> This is very strange, it should not be possible to loose a dse.ldif,
> although you are now teh second person reporting this. I have seen 0 length
> dse.ldif.tmp if a VM was powerd off while ds was active, but from DS  point
> of view it is not possible to complete loos the dse.ldif.
> The dse.ldif stores the configuration information including replication
> agreements and and when ever this is updated the new state is written to
> disk. The procedure is like this:
> -create a dse.ldif.tmp (this is the only time a 0 byte dse.ldif* file
> exists
> -write the config to dse.ldif.tmp
> -rename dse.ldif to dse.ldif.bak
> -rename dse.ldif.tmp to dse.ldif
>
> So, if the machine or the server crashes during this process there should
> be always a dse.ldif.tmp or dse.ldif.bak containing the current or latest
> information. If anyone has an idea how on a VM when powering it off can
> completely loose these files I would like to know.
>
> However, I see some errors in dirsrv's logs. It is constantly printing
> lines like "DSRetroclPlugin - delete_changerecord: could not delete change
> record 418295". Is that normal ?
>
> Unfortunately it can be. If after a crash the beginning of the retro cl is
> incorrectly calculated, changelog trimming might try to remov no longer
> existing records, it is annoying but harmless, so far we have not further
> investigated how to prevent this.
>
> How do I confirm that the replica is back and fully functional ? Why did
> this happen in the first place ?
>
> On Wed, Apr 27, 2016 at 1:41 PM, Gady Notrica <gnotr...@candeal.com>
> wrote:
>
>> All good!!!
>>
>> Gady
>>
>> -Original Message-
>> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>> Sent: April 27, 2016 1:19 PM
>> To: Gady Notrica
>> Cc: Ludwig Krispenz; freeipa-users@redhat.com
>> Subject: Re: [Freeipa-users] krb5kdc service not starting
>>
>> On Wed, 27 Apr 2016, Gady Notrica wrote:
>> >Hello Ludwig,
>> >
>> >Is there a reason why my AD show offline?
>> >
>> >[root@cd-p-ipa1 /]# wbinfo --online-status BUILTIN : online IPA :
>> >online CD-PRD : offline
>> wbinfo output is irrelevant for RHEL 7.2-based IPA trusts.
>>
>> You need to make sure that 'getent passwd CD-PRD\\Administrator'
>> resolves via SSSD.
>>
>> --
>> / Alexander Bokovoy
>>
>> --
>> Manage your subscription fo

Re: [Freeipa-users] krb5kdc service not starting

[Prasun Gera]

Hi everyone,
I had a pretty similar failure on my replica yesterday. The replica was not
reachable, and I asked someone to have a look at the system. They
presumably rebooted it. When it came back up, ipactl wouldn't start, and
the symptoms were pretty similar to those described in this thread. I
followed the solution of copying dse.ldif.startOK to dse.ldif, and that
started everything. However, I see some errors in dirsrv's logs. It is
constantly printing lines like "DSRetroclPlugin - delete_changerecord:
could not delete change record 418295". Is that normal ? How do I confirm
that the replica is back and fully functional ? Why did this happen in the
first place ?

On Wed, Apr 27, 2016 at 1:41 PM, Gady Notrica  wrote:

> All good!!!
>
> Gady
>
> -Original Message-
> From: Alexander Bokovoy [mailto:aboko...@redhat.com]
> Sent: April 27, 2016 1:19 PM
> To: Gady Notrica
> Cc: Ludwig Krispenz; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] krb5kdc service not starting
>
> On Wed, 27 Apr 2016, Gady Notrica wrote:
> >Hello Ludwig,
> >
> >Is there a reason why my AD show offline?
> >
> >[root@cd-p-ipa1 /]# wbinfo --online-status BUILTIN : online IPA :
> >online CD-PRD : offline
> wbinfo output is irrelevant for RHEL 7.2-based IPA trusts.
>
> You need to make sure that 'getent passwd CD-PRD\\Administrator'
> resolves via SSSD.
>
> --
> / Alexander Bokovoy
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Account/password expirations

[Prasun Gera]

It turns out that this was a permissions issue. Everything works now.
Thanks.

On Sat, Apr 30, 2016 at 11:26 PM, Prasun Gera <prasun.g...@gmail.com> wrote:

> Ah, this doesn't work on ubuntu (14.04). The command itself works, but
> sshd on ubuntu isn't probably compiled with support for this although I see
> "AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys" in sshd_config. I
> don't think the freeipa/sssd ppas package sshd. Any way to get this working
> on ubuntu 14.04 ?
>
> On Fri, Apr 29, 2016 at 12:30 PM, Anon Lister <listera...@gmail.com>
> wrote:
>
>> Yep sorry I missed that. You need to put your public keys in IPA.
>> On Apr 29, 2016 3:32 AM, "Jakub Hrozek" <jhro...@redhat.com> wrote:
>>
>> On Thu, Apr 28, 2016 at 09:14:48PM -0400, Prasun Gera wrote:
>> > >
>> > > Your can still authenticate with SSH keys, but to access any NFS 4
>> shares
>> > > they will need a Kerberos ticket, which can be obtained via a 'kinit'
>> after
>> > > logging in.
>> > >
>> >
>> > Then how does the key authentication work if the .ssh directory on nfs4
>> is
>> > not accessible ?  Doesn't the key authentication process rely on
>> > .ssh/authorized keys being readable by the authentication module ?
>>
>> SSSD can fetch the authorized keys from IPA, see man
>> sss_ssh_authorizedkeys(1)
>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Account/password expirations

[Prasun Gera]

Ah, this doesn't work on ubuntu (14.04). The command itself works, but sshd
on ubuntu isn't probably compiled with support for this although I see
"AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys" in sshd_config. I
don't think the freeipa/sssd ppas package sshd. Any way to get this working
on ubuntu 14.04 ?

On Fri, Apr 29, 2016 at 12:30 PM, Anon Lister <listera...@gmail.com> wrote:

> Yep sorry I missed that. You need to put your public keys in IPA.
> On Apr 29, 2016 3:32 AM, "Jakub Hrozek" <jhro...@redhat.com> wrote:
>
> On Thu, Apr 28, 2016 at 09:14:48PM -0400, Prasun Gera wrote:
> > >
> > > Your can still authenticate with SSH keys, but to access any NFS 4
> shares
> > > they will need a Kerberos ticket, which can be obtained via a 'kinit'
> after
> > > logging in.
> > >
> >
> > Then how does the key authentication work if the .ssh directory on nfs4
> is
> > not accessible ?  Doesn't the key authentication process rely on
> > .ssh/authorized keys being readable by the authentication module ?
>
> SSSD can fetch the authorized keys from IPA, see man
> sss_ssh_authorizedkeys(1)
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Account/password expirations

[Prasun Gera]

>
> Your can still authenticate with SSH keys, but to access any NFS 4 shares
> they will need a Kerberos ticket, which can be obtained via a 'kinit' after
> logging in.
>

Then how does the key authentication work if the .ssh directory on nfs4 is
not accessible ?  Doesn't the key authentication process rely on
.ssh/authorized keys being readable by the authentication module ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Account/password expirations

[Prasun Gera]

>
> Moreover, if you login through an SSH key, you don't get a ticket on
> login and you can't kinit, so you can't access any network resources
> anyway..
>
>
A bit off topic, but a related question:
How does nfsv4 work with ssh keys ? Does it mean that you can't use ssh
keys if /home is nfsv4 mounted ? I had tried nfsv4 briefly, but had some
issues, and didn't look it in too much detail. Also, is it possible to use
nfsv4 home in an HPC cluster environment where something like torque or
slurm schedules jobs ? For nfsv3, I suppose the workload manager runs as
the user, and hence it can read/write to the user's directory. Would it
still be possible to do that in an nfsv4 system ? How would renewals happen
for long running jobs without any user interaction ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] deleting duplicate groups with groupdel

[Prasun Gera]

Yes, getent passwd shows the users, and sssd.conf didn't have
enumerate=true. As it turns out, this happens because ypbind was running on
the server, which binds to ipa's fake nis server on the same machine. Once
I stopped ypbind, I was able to delete those groups. This was an
interesting case.

On Wed, Apr 13, 2016 at 3:28 AM, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Wed, Apr 13, 2016 at 12:30:56AM -0400, Prasun Gera wrote:
> > My main ipa server used to be an NIS server. After migrating everything
> > into ipa, there is no need for the users and groups to exist in
> /etc/passwd
> > and /etc/group. Leaving them around would cause duplicate entries,
> > passwords falling out of sync and other issues on the server. So the
> right
> > approach is to delete all the local users and groups, and let ipa handle
> > everything. I was able to delete all the local users from /etc/passwd.
> > However, groupdel won't let me delete the local groups. It complains that
> > xyz user's primary group is abc and hence you can't delete it.  The user
> > itself is not a part of /etc/passwd anymore. This is a bug as far as I
> can
> > tell. groupdel should check these constraints only for local users and
> > local groups. It shouldn't mix ipa users and ipa groups with them.
> >
> > Environment: RHEL 7.2, idm 4.x
>
> Looking at groupdel code, they just loop through all users with
> getpwent and report a primary group if any of the enumerated users
> matched the gid trying to be removed.
>
> So I would only expect this to happen if enumerate=true is set in
> sssd.conf, otherwise it should not be possible to reach those users with
> getpwent (if you removed them from passwd already). As a quick check,
> you can see if "getent passwd" without a user argument shows those
> users.
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] deleting duplicate groups with groupdel

[Prasun Gera]

My main ipa server used to be an NIS server. After migrating everything
into ipa, there is no need for the users and groups to exist in /etc/passwd
and /etc/group. Leaving them around would cause duplicate entries,
passwords falling out of sync and other issues on the server. So the right
approach is to delete all the local users and groups, and let ipa handle
everything. I was able to delete all the local users from /etc/passwd.
However, groupdel won't let me delete the local groups. It complains that
xyz user's primary group is abc and hence you can't delete it.  The user
itself is not a part of /etc/passwd anymore. This is a bug as far as I can
tell. groupdel should check these constraints only for local users and
local groups. It shouldn't mix ipa users and ipa groups with them.

Environment: RHEL 7.2, idm 4.x
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Disabling passwd NIS map

[Prasun Gera]

I have a master + replica setup on RHEL 7.2 (ipa 4.2). When this was setup,
most of the clients were on NIS, and hence the nis compatibility and
migration mode was enabled. The NIS maps in use right now are passwd, group
and autofs. Passwords were set to CRYPT for this to work. I have managed to
join all the clients to ipa now. So I would like to disable the passwd
maps, or at least make them benign. I would also like to switch back to
SSHA for passwords, or whatever else is recommended. However, I don't want
to disable the other NIS maps yet. autofs doesn't work well on old clients
with sssd, and regularly gives trouble with new clients too. I think there
are some uses for the group map too. I think group and autofs aren't major
security issues right ?

How do I go about achieving this ? I have no experience with modifying ldap
files directly. If I have to modify files manually, do I have to do it on
the master and replica ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA users central Home Directories

[Prasun Gera]

NFS and ipa are sort of orthogonal unless you mix nfsv4 with kerberos. If
you aren't using kerberos, and don't need kerberos, then the nfs home setup
is pretty straightforward. ipa just controls authentication. If you have a
simple enough environment, you can just add your nfs mounts in the fstab of
clients. If you have something more complex, you can use autofs too, but
that will involve using sssd as the automount provider. There is an ipa
automount setup command which does that configuration. All of this should
also work with nfsv4 and kerberos too, but that just adds another variable
to the mix for debugging.

HA for home directories: There are a lot of file systems with different
properties. That is again pretty orthogonal to ipa.

On Tue, Mar 29, 2016 at 3:07 AM, Shahzad Malik <
shahzad.ma...@m5networks.com.au> wrote:

> Hi
>
>
> I have recently configured IPA master and replica server. I am trying to
> configure IPA users central home directories which means when a user
> authenticate through IPA on any client, will have same home directory. To
> achieve this goal, I have configured a NFS server, joined and configured
> nfs with IPA.
>
> I have Rhel 7 and CentOS  7 clients. Rhel clients are working as expected,
> when IPA users are authenticated on Rhel clients they can get home
> directory from nfs server. df -h shows any entry of nfs user home directory
> mounted.
>
> When a client is Centos 7, users are able to authenticated from IPA and
> can login but can't get home directory from NFS server. I can manually
> mount a dir with nfs server which verifies communication is working between
> centos client and nfs.
>
> All neccesary ports are open and centos configurations are pretty much
> same as Rhel clients. I even disabled selinux, but no luck. Has anyone
> experienced same issue?
>
> Another question: At the moment, there is single nfs serve which is single
> point of failure, what best method I can use for HA of user home
> directories?
>
> Many Thanks
>
>
> Regards,
>
>
> Shez
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Fwd: [freeipa-users] Configuring Automount on Ubuntu Clients

[Prasun Gera]

That could be an nfs v3 v/s v4 issue. I had a similar issue, which I
resolved by setting nfs to v3 at mount time.

On Wed, Feb 17, 2016 at 8:01 AM, Philippe Domineaux <pdomine...@gmail.com>
wrote:

> Hello,
>
> and don’t you have any issues with the display of files owners.
> I can only see nobody as the owner/group for files?
>
>
> Le 17 février 2016 à 02:08:51, Domineaux Philippe (pdomine...@gmail.com)
> a écrit:
>
>
> -- Forwarded message --
> From: Filip Pytloun <fi...@pytloun.cz>
> Date: 2016-02-14 8:14 GMT+01:00
> Subject: Re: [Freeipa-users] [freeipa-users] Configuring Automount on
> Ubuntu Clients
> To: freeipa-users@redhat.com
>
>
> Hello,
>
> we are using Ubuntu 14.04 on FreeIPA clients and Ubuntu 16.04 on FreeIPA
> server for 2 months with no critical issues.
>
> Using newer freeipa-client was not needed, only sssd update from here,
> because trusty version is buggy:
>
> https://launchpad.net/~sssd/+archive/ubuntu/updates?field.series_filter=trusty
>
> On server side, it was only needed to fix apparmor policy for bind to
> fix FreeIPA DNS zones:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814314
>
> Maybe someone could be interested in Salt formula we are using to setup
> Freeipa server/client: https://github.com/tcpcloud/salt-formula-freeipa
>
> Filip
>
> On 2016/02/13 17:40, Prasun Gera wrote:
> > Just replying to this thread to express interest in good client support
> in
> > Ubuntu. As 16.04 draws close to a release, it would be great if the
> client
> > side of things work well out of the box in 16.04 without any 3rd party
> > ppas. 12.04 was pretty bad, 14.04 was mostly usable with some issues. I'm
> > hoping that with 16.04, it reaches parity with Fedora based distros. I'll
> >  be happy to do some preliminary testing if needed.
> >
> > On Mon, Feb 8, 2016 at 10:56 AM, Timo Aaltonen <tjaal...@ubuntu.com>
> wrote:
> >
> > > 04.02.2016, 19:28, Jon kirjoitti:
> > > > Is Ubuntu not supported with FreeIPA?  Is there an updated install
> > > > script?  I installed the freeipa-client from public repos.
> > > >
> > > >>> ii  freeipa-client
> > > >  3.3.4-0ubuntu3.1amd64
> > > >  FreeIPA centralized identity framework -- client
> > > >>> ii  python-freeipa
> > > >  3.3.4-0ubuntu3.1amd64
> > > >  FreeIPA centralized identity framework -- python modules
> > >
> > > The stock packages in 14.04 are rather old, you'd probably be happier
> with
> > > the 4.0.5-based client available on the PPA:
> > >
> > > https://launchpad.net/~freeipa/+archive/ubuntu/4.0
> > >
> > >
> > >
> > > --
> > > t
> > >
> > > --
> > > Manage your subscription for the Freeipa-users mailing list:
> > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > > Go to http://freeipa.org for more info on the project
> > >
>
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
> --
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] [freeipa-users] Configuring Automount on Ubuntu Clients

[Prasun Gera]

Just replying to this thread to express interest in good client support in
Ubuntu. As 16.04 draws close to a release, it would be great if the client
side of things work well out of the box in 16.04 without any 3rd party
ppas. 12.04 was pretty bad, 14.04 was mostly usable with some issues. I'm
hoping that with 16.04, it reaches parity with Fedora based distros. I'll
 be happy to do some preliminary testing if needed.

On Mon, Feb 8, 2016 at 10:56 AM, Timo Aaltonen  wrote:

> 04.02.2016, 19:28, Jon kirjoitti:
> > Is Ubuntu not supported with FreeIPA?  Is there an updated install
> > script?  I installed the freeipa-client from public repos.
> >
> >>> ii  freeipa-client
> >  3.3.4-0ubuntu3.1amd64
> >  FreeIPA centralized identity framework -- client
> >>> ii  python-freeipa
> >  3.3.4-0ubuntu3.1amd64
> >  FreeIPA centralized identity framework -- python modules
>
> The stock packages in 14.04 are rather old, you'd probably be happier with
> the 4.0.5-based client available on the PPA:
>
> https://launchpad.net/~freeipa/+archive/ubuntu/4.0
>
>
>
> --
> t
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] client/authentication inside a docker container

[Prasun Gera]

On Thu, Feb 4, 2016 at 4:23 PM, Nordgren, Bryce L -FS <bnordg...@fs.fed.us>
wrote:

> An RHEL 7 host filesystem may have the same basic structure as an Ubuntu
> trusty container filesystem, but may have different users defined,
> particularly for running services and for owning the files those services
> must touch. To what extent do you want the same users to be enforced
> between the container and the host? Is it OK for service accounts to be
> different, as long as user/login/people accounts are the same?
>
>
>
Yes, that would be OK. I think all I need is that the files touched inside
the container look consistent permissions-wise to files that you see on the
host, and vice-versa. As such, I don't need authentication inside the
container since we don't need to host any services in the container. I just
need 1:1 mapping for uid:gid for regular users.


> It almost sounds like you’re using containers to isolate user environments
> and processes, but you’re accumulating data from/sharing data between
> containers…Which implies that the processes generating the data run as the
> user and not as a system service. It may be easier to wrap whatever program
> you’re running as a web service so the users don’t have to log in and your
> uid:gid problem goes away.
>
>
>
Yes, I've just got started with Docker, and trying to use it as a way to
isolate development environment. We have a tool which has some weird
toolchain dependencies (old versions of gcc, boost, bison, and possibly a
few others), which would make it very hacky to compile/run it natively on
all systems. I think docker solves that problem such that whenever the use
wants to use that tool, they can just drop into the docker container and
work there.


> Bryce
>
>
>
> *From:* freeipa-users-boun...@redhat.com [mailto:
> freeipa-users-boun...@redhat.com] *On Behalf Of *Prasun Gera
> *Sent:* Thursday, February 04, 2016 8:19 AM
> *To:* freeipa-users@redhat.com
> *Subject:* [Freeipa-users] client/authentication inside a docker container
>
>
>
> I am trying to set up a docker image with a specific development
> environment. We use idm 4.2 for authentication, and non-kerberized nfs
> (including home) for data storage on the hosts. The goal is to run the
> docker container such that when the user calls docker run, it just drops
> into a shell with the container's environment, but everything else looks
> largely the same. i.e. The user gets the same uid:gid and sees the same
> directories and permissions as the host. I'm trying to figure out what the
> best way of mapping user ids is. I've looked at the following options:
>
>- ipa-client-install inside the container. This has a few problems.
>One is hostname and DNS. Container needs an fqdn for this to work, and the
>dns has to resolve this hostname. We are not using IPA's DNS. So this whole
>approach looks very kludgy. Besides, I'm not sure what the right way of
>handling these ephemeral host names is. Ideally, they should be un-enrolled
>when the container is destroyed,
>- Use ipa's fake NIS. This works, and is very simple to setup, but I
>think we want to phase out NIS. If we start using it inside docker, it will
>never die
>- Don't do any domain authentication. Just ask the user to create a
>user with the same uid:gid as the host so that they can r/w to their own
>directories.
>
> The ipa version is 4.2 running on RHEL 7. The container image will be
> based on ubuntu trusty. Hosts are a mix of different OSes.
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] client/authentication inside a docker container

[Prasun Gera]

I am trying to set up a docker image with a specific development
environment. We use idm 4.2 for authentication, and non-kerberized nfs
(including home) for data storage on the hosts. The goal is to run the
docker container such that when the user calls docker run, it just drops
into a shell with the container's environment, but everything else looks
largely the same. i.e. The user gets the same uid:gid and sees the same
directories and permissions as the host. I'm trying to figure out what the
best way of mapping user ids is. I've looked at the following options:

   - ipa-client-install inside the container. This has a few problems. One
   is hostname and DNS. Container needs an fqdn for this to work, and the dns
   has to resolve this hostname. We are not using IPA's DNS. So this whole
   approach looks very kludgy. Besides, I'm not sure what the right way of
   handling these ephemeral host names is. Ideally, they should be un-enrolled
   when the container is destroyed,
   - Use ipa's fake NIS. This works, and is very simple to setup, but I
   think we want to phase out NIS. If we start using it inside docker, it will
   never die
   - Don't do any domain authentication. Just ask the user to create a user
   with the same uid:gid as the host so that they can r/w to their own
   directories.

The ipa version is 4.2 running on RHEL 7. The container image will be based
on ubuntu trusty. Hosts are a mix of different OSes.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] client/authentication inside a docker container

[Prasun Gera]

On Thu, Feb 4, 2016 at 10:56 AM, Jan Pazdziora <jpazdzi...@redhat.com>
wrote:

> On Thu, Feb 04, 2016 at 10:19:16AM -0500, Prasun Gera wrote:
> > I am trying to set up a docker image with a specific development
> > environment. We use idm 4.2 for authentication, and non-kerberized nfs
> > (including home) for data storage on the hosts.
>
> Are the hosts IPA-enrolled?
>
> Yes.


> > The goal is to run the
> > docker container such that when the user calls docker run,
>
> Is any user allowed to run docker run? That seems like a security
> issue.
>
> Well any user that can do sudo should be able to run docker. Is there a
security issue with that ?


> > it just drops
> > into a shell with the container's environment, but everything else looks
> > largely the same. i.e. The user gets the same uid:gid and sees the same
> > directories and permissions as the host.
>
> So you want bash started in the container, with the uid:gid of the
> person invoking the command? If the users are trusted to do docker
> run, they can do
>
> docker run -u $UID container bash
>
> themselves.
>
> Yes, this is similar to the 3rd point I mentioned. The problem though is
that directory listings will not show names inside the container. They'll
only show uids and gids. NIS solves this as a quick hack, but is there
something better ? Permissions would still work since NFS is not
kerberized. Another issue I haven't figured out is how the user can get
sudo inside the container. If you start docker with the user's uid, I don't
know if there is a safe way for that user to get sudo inside. If you start
docker in the root shell, you can create the user with the uid:gid, add it
to sudoers, and then change to the user's shell ?


> But you likely do not want to give every user a way to run any command,
> why not just use sudo, and
>
> docker run -u $SUDO_UID container bash
>
> in the script invoked with the sudo (untested)?
>
> I didn't follow this. Can you explain a bit more ? In the default setup,
you anyway need sudo to run docker. What is the -u string here ?

--
> Jan Pazdziora
> Senior Principal Software Engineer, Identity Management Engineering, Red
> Hat
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FREAK Vulnerability

[Prasun Gera]

Can someone at RH update this article
https://access.redhat.com/articles/1467293 ? I found it to be fairly
useful, but I'm not sure if it's up to date.

On Thu, Jan 28, 2016 at 11:04 AM, Terry John <
terry.j...@completeautomotivesolutions.co.uk> wrote:

> Ok thanks for that but I've had to give up, our freeipa server is too
> critical to our business for me to continue even with outages of one or two
> minutes.
>
> The Ciphers below were not recognised and when I just tried to remove the
> export ciphers from the original list I got this error
> (Netscape Portable Runtime error -12266 - An unknown SSL cipher suite has
> been requested.)
>
> A type or a fundamental problem I don't know.
>
> I am working in an AWS environment and have tried making a clone and
> working on that but freeipa just gets confused and stops. I suppose another
> alternative is to build a freeipa server from scratch and work on that.
> Seems an awful lot of work to remove one cipher :-(
>
> terry
>
> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com]
> Sent: 28 January 2016 14:35
> To: Terry John; Marat Vyshegorodtsev; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] FREAK Vulnerability
>
> Terry John wrote:
> > I'm really confused now. After the problem where my feeipa server would
> not start and I had to use the backup I'm trying to do things in small
> steps.
> >
> > Listening to everything that has been said (thanks) I edited
> > slapd-/dse.ldif slapd-PKI-IPA/dse.ldif and changed the lines
> >
> > nsSSL3Ciphers:  
> > to
> > nsSSL3Ciphers:+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_g
> > cm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+
> > ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_
> > 128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes
> > _128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_25
> > 6_sha
> > (There is a space after the colon)
> >
> > Then I did a 'service ip restart' and when I looked the dse.ldif files
> had reverted back to their original settings..
> >
> > Where am I going wrong?
>
> dse.ldif is written out when the server shuts down so any changes you make
> to it while 389-ds is running are lost.
>
> rob
>
> >
> > Terry
> >
> >
> > -Original Message-
> > From: Rob Crittenden [mailto:rcrit...@redhat.com]
> > Sent: 28 January 2016 04:49
> > To: Marat Vyshegorodtsev; Terry John; freeipa-users@redhat.com
> > Subject: Re: [Freeipa-users] FREAK Vulnerability
> >
> > Marat Vyshegorodtsev wrote:
> >> My two cents:
> >>
> >> My "magic" string for NSS is like this (I had to move to Fedora 23
> >> from CentOS in order to get more recent NSS version though):
> >>
> >> NSSProtocol TLSv1.2
> >> NSSCipherSuite
> >> -All,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdh_ecdsa_ae
> >> s
> >> _128_sha,+ecdh_ecdsa_aes_256_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecds
> >> a
> >> _aes_256_sha,+aes_256_sha_256,+aes_128_sha_256,+rsa_aes_128_gcm_sha_2
> >> 5
> >> 6,+ecdhe_ecdsa_aes_128_sha_256,+ecdhe_rsa_aes_128_sha_256,+ecdhe_ecds
> >> a
> >> _aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_gcm_sha_256
> >
> > The -All is a syntax error (ignored). All ciphers are disabled by
> default anyway.
> >
> > I'd suggest using the ticket already referenced as a starting point.
> >
> > /usr/lib[64]/nss/unsupported-tools/listsuites is also handy to see what
> is enabled by default in NSS (though again, everything is disabled by
> mod_nss at startup).
> >
> > rob
> >
> >>
> >> My cert is ECDSA private CA though. If you are interested, I can give
> >> you my chef recipe snippets to configure it.
> >>
> >> On Thu, Jan 28, 2016 at 11:02 AM, Marat Vyshegorodtsev
> >>  wrote:
> >>> My two cents:
> >>>
> >>> My "magic" string for NSS is like this (I had to move to Fedora 23
> >>> from CentOS in order to get more recent NSS version though):
> >>>
> >>> NSSProtocol TLSv1.2
> >>> NSSCipherSuite
> >>> -All,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdh_ecdsa_a
> >>> e
> >>> s_128_sha,+ecdh_ecdsa_aes_256_sha,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ec
> >>> d
> >>> sa_aes_256_sha,+aes_256_sha_256,+aes_128_sha_256,+rsa_aes_128_gcm_sh
> >>> a
> >>> _256,+ecdhe_ecdsa_aes_128_sha_256,+ecdhe_rsa_aes_128_sha_256,+ecdhe_
> >>> e
> >>> cdsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_gcm_sha_256
> >>>
> >>> My cert is ECDSA private CA though. If you are interested, I can
> >>> give you my chef recipe snippets to configure it.
> >>>
> >>> Marat
> >>>
> >>> On Fri, Jan 22, 2016 at 1:54 AM, Terry John
> >>>  wrote:
> >> I've been trying to tidy the security on my FreeIPA and this is
> >> causing me some problems. I'm using OpenVAS vulnerability scanner
> >> and it is coming up with this issue
> >>
> >> EXPORT_RSA cipher suites supported by the remote server:
> >> TLSv1.0: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0006)
> >> TLSv1.0: 

Re: [Freeipa-users] Announcing FreeIPA 4.3.0 - demo

[Prasun Gera]

This is great. Can you post instructions for getting Let's Encrypt working
on 4.2.x ? I had created a thread, but I eventually got stuck, and it felt
a bit risky to modify low level things on a production system.

This is the thread for reference:
https://www.redhat.com/archives/freeipa-users/2015-November/msg00048.html

I got as far as adding the root cert manually, but it still didn't work
after that.

On Fri, Jan 15, 2016 at 4:16 AM, Martin Kosek  wrote:

> On 12/18/2015 06:24 PM, Petr Vobornik wrote:
> > The FreeIPA team would like to announce FreeIPA v4.3.0 release!
> >
> > It can be downloaded from http://www.freeipa.org/page/Downloads. The
> builds are
> > available for Fedora rawhide. Builds for Fedora 23 are available in the
> > official COPR repository
> > .
> >
> > This announcement is also available at
> > .
> >
> > == Highlights in 4.3.0 ==
> > * Simplified management of replication topology - control and display
> your
> > topology from CLI and UI
> > * Simplified replica installation - install replica without ''replica
> package''
> > via OTP, keytab or privileged user credentials. The new method is called
> > ''replica promotion'' as it adds FreeIPA server capability to existing
> or new
> > client
> > ...
>
> FreeIPA demo [1] was upgraded to version 4.3.0. Compared to previous Demo
> version (4.2.x), you can now see the new Topology tab in "IPA Server"
> section,
> to get information about the FreeIPA servers in the realm, including a very
> thrilling Topology Graph :-)
>
> The Apache service was also updated to use a trusted certificate from Let's
> Encrypt, so you no longer need to waive the nasty Certificate Warning.
> Thanks
> to Petr Spacek and Jan Cholasta for helping me setting it up.
>
> [1] http://www.freeipa.org/page/Demo
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA users not visible in NIS passwd map

[Prasun Gera]

They are authenticated using CRYPT passwords. i.e. Even after a user is
disabled in ipa, it's entry is still visible in ypcat passwd on the
clients.

On Wed, Jan 13, 2016 at 4:17 PM, Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On Wed, 13 Jan 2016, Prasun Gera wrote:
>
>> I think I've solved this. I don't know what or who enabled it, but for
>> some
>> reason the original NIS service (ypserv) was running on the server. That
>> was taking precedence over ipa's fake NIS, and causing problems. I have
>> now
>> deleted the maps and commented them out in the Makefile so that it doesn't
>> get enabled accidentally again.
>>
>> I do see another problem though. In an attempt to clean up a lot of old
>> users, I have disabled them in the webui. This works for ipa clients and
>> access is denied, but the users can still log in on the old NIS clients.
>> Is
>> this a known limitation ?
>>
> How they are authenticated on the NIS clients? FreeIPA does not provide
> shadow map.
> --
> / Alexander Bokovoy
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA users not visible in NIS passwd map

[Prasun Gera]

I think I've solved this. I don't know what or who enabled it, but for some
reason the original NIS service (ypserv) was running on the server. That
was taking precedence over ipa's fake NIS, and causing problems. I have now
deleted the maps and commented them out in the Makefile so that it doesn't
get enabled accidentally again.

I do see another problem though. In an attempt to clean up a lot of old
users, I have disabled them in the webui. This works for ipa clients and
access is denied, but the users can still log in on the old NIS clients. Is
this a known limitation ?

On Mon, Jan 11, 2016 at 9:21 PM, Prasun Gera <prasun.g...@gmail.com> wrote:

> This is the output of the command:
>
> ldapsearch  -LLL -H $(cat /etc/ipa/default.conf | grep ldap_uri|cut -d=
> -f2) -b cn=config '(nis-domain=*)' dn CreateTimestamp ModifyTimestamp
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> dn: nis-domain=domain.edu+nis-map=auto.home,cn=NIS
> Server,cn=plugins,cn=config
> CreateTimestamp: 20150321091139Z
> ModifyTimestamp: 20150321091139Z
>
> dn: nis-domain=domain.edu+nis-map=auto.local,cn=NIS
> Server,cn=plugins,cn=confi
>  g
> CreateTimestamp: 20150321091209Z
> ModifyTimestamp: 20150321091209Z
>
> dn: nis-domain=domain.edu+nis-map=auto.master,cn=NIS
> Server,cn=plugins,cn=conf
>  ig
> CreateTimestamp: 20150321091201Z
> ModifyTimestamp: 20150321091201Z
>
> dn: nis-domain=domain.edu+nis-map=ethers.byaddr,cn=NIS
> Server,cn=plugins,cn=co
>  nfig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=ethers.byname,cn=NIS
> Server,cn=plugins,cn=co
>  nfig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=group.bygid,cn=NIS
> Server,cn=plugins,cn=conf
>  ig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=group.byname,cn=NIS
> Server,cn=plugins,cn=con
>  fig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=netgroup,cn=NIS
> Server,cn=plugins,cn=config
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=netid.byname,cn=NIS
> Server,cn=plugins,cn=con
>  fig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=passwd.byname,cn=NIS
> Server,cn=plugins,cn=co
>  nfig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
> dn: nis-domain=domain.edu+nis-map=passwd.byuid,cn=NIS
> Server,cn=plugins,cn=con
>  fig
> CreateTimestamp: 20150320220124Z
> ModifyTimestamp: 20150320220124Z
>
>
> All the maps are listed from what I can tell. passwd is the one that is
> not working as expected. Autofs maps are working all right on nis clients.
>
> On Mon, Jan 11, 2016 at 4:21 PM, Alexander Bokovoy <aboko...@redhat.com>
> wrote:
>
>> On Mon, 11 Jan 2016, Prasun Gera wrote:
>>
>>> I upgraded ipa to 4.2 on my rhel 7.2 servers a few weeks ago. One of the
>>> users reported that he is not able to log in to certain systems any more.
>>> It turns out that there is some change in behaviour w.r.t NIS clients
>>> after
>>> this upgrade. I see that his username is not visible in "ypcat passwd" on
>>> the old clients that are using NIS. This user was added natively through
>>> ipa. The old users that were migrated from NIS still work as expected on
>>> the NIS clients. I can also confirm that if I add a new user now in ipa,
>>> it
>>> is not visible in NIS maps. Until we phase out the NIS clients
>>> completely,
>>> I would like all users to be able to log into them. This used to be the
>>> case, but a recent update seems to have changed that. I don't know if
>>> this
>>> is intentional. How do i revert to the old behaviour ?
>>>
>> Do you see all the maps configured?
>>
>> # ldapsearch  -LLL -H $(cat /etc/ipa/default.conf | grep ldap_uri|cut -d=
>> -f2) -b cn=config '(nis-domain=*)' dn CreateTimestamp ModifyTimestamp
>>
>> We have a bug in the upgrade script that was fixed this morning
>> https://www.redhat.com/archives/freeipa-devel/2016-January/msg00154.html
>>
>> --
>> / Alexander Bokovoy
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA users not visible in NIS passwd map

[Prasun Gera]

Great! I hope it makes it downstream to RHEL.

On Wed, Jan 13, 2016 at 4:27 PM, Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On Wed, 13 Jan 2016, Prasun Gera wrote:
>
>> They are authenticated using CRYPT passwords. i.e. Even after a user is
>> disabled in ipa, it's entry is still visible in ypcat passwd on the
>> clients.
>>
> https://fedorahosted.org/slapi-nis/ticket/10
>
> The definition is unfortunately in the C code, so it would require
> recompile of slapi-nis. For Fedora I plan to do new release next week or
> so as there are enough patches ready to go to new release.
>
>
> --
> / Alexander Bokovoy
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] GID, groups and ipa group-show

[Prasun Gera]

This is an old thread, but I can confirm that this is still an issue on
RHEL 7.2 + 4.2. This creates problems when there are roles associated with
groups, but group membership through GID is broken. I had migrated all old
NIS accounts into ipa. I then added the host enrollment role to a
particular group. Now, unless I add the users to the group explicitly, they
won't get the role, even if their gid is the same as the gid of the group.

On Mon, Aug 24, 2015 at 5:01 AM, David Kupka  wrote:

> On 21/08/15 15:21, bahan w wrote:
>
>> Hello !
>>
>> I contact you because I notice something strange with IPA environment.
>>
>> I created a group :
>> ipa group-add g1 --desc="my first group"
>>
>> Then I created a user with the GID of g1
>> GID1=`ipa group-show g1 | awk '/GID/ {printf("%s",$2)}'`
>> ipa user-add --first=u1 --last=u1 --homedir=/home/u1 --shell=/bin/bash
>> --gidnumber=${GID1} u1
>>
>> Then when I perform ipa group-show g1 command, I got the following result
>> :
>> ###
>>Group name: g1
>>Description: my first group
>>GID: 
>> ###
>>
>> Same for ipa user-show u1 :
>> ###
>>User login: u1
>>First name: u1
>>Last name: u1
>>Home directory: /home/u1
>>Login shell: /bin/bash
>>Email address: u1@
>>UID: 
>>GID: 
>>Account disabled: False
>>Password: False
>>Member of groups: ipausers
>>Kerberos keys available: False
>> ###
>>
>> These 2 commands does not see u1 as a member of g1.
>> When I try the command id u1, I can see the group :
>>
>> ###
>> id u1
>> uid=(u1) gid=(g1) groups=(g1)
>> ###
>>
>> Is it the normal behaviour of these IPA commands ?
>>
>> Best regards.
>>
>> Bahan
>>
>>
>>
> Hello!
>
> I'm not sure if this is intended and/or correct behavior or not.
> Looking at /etc/passwd and /etc/group I see it behaves similarly in a way.
>
> You can have following entries in the aforementioned files
>
> [/etc/group]
> ...
> g1:x::
> ...
>
> [/etc/passwd]
> ...
> u1:x/home/u1:/bin/bash
> ...
>
> Looking in /etc/group you can't see user 'u1' is member of group 'g1' but
> tools like id, groups, getent shows this information.
>
> On the other hand it would be useful to show these "implicit" members in
> group-show output.
> Could you please file a ticket (https://fedorahosted.org/freeipa/newticket
> )?
>
> --
> David Kupka
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA users not visible in NIS passwd map

[Prasun Gera]

This is the output of the command:

ldapsearch  -LLL -H $(cat /etc/ipa/default.conf | grep ldap_uri|cut -d=
-f2) -b cn=config '(nis-domain=*)' dn CreateTimestamp ModifyTimestamp
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: nis-domain=domain.edu+nis-map=auto.home,cn=NIS
Server,cn=plugins,cn=config
CreateTimestamp: 20150321091139Z
ModifyTimestamp: 20150321091139Z

dn: nis-domain=domain.edu+nis-map=auto.local,cn=NIS
Server,cn=plugins,cn=confi
 g
CreateTimestamp: 20150321091209Z
ModifyTimestamp: 20150321091209Z

dn: nis-domain=domain.edu+nis-map=auto.master,cn=NIS
Server,cn=plugins,cn=conf
 ig
CreateTimestamp: 20150321091201Z
ModifyTimestamp: 20150321091201Z

dn: nis-domain=domain.edu+nis-map=ethers.byaddr,cn=NIS
Server,cn=plugins,cn=co
 nfig
CreateTimestamp: 20150320220124Z
ModifyTimestamp: 20150320220124Z

dn: nis-domain=domain.edu+nis-map=ethers.byname,cn=NIS
Server,cn=plugins,cn=co
 nfig
CreateTimestamp: 20150320220124Z
ModifyTimestamp: 20150320220124Z

dn: nis-domain=domain.edu+nis-map=group.bygid,cn=NIS
Server,cn=plugins,cn=conf
 ig
CreateTimestamp: 20150320220124Z
ModifyTimestamp: 20150320220124Z

dn: nis-domain=domain.edu+nis-map=group.byname,cn=NIS
Server,cn=plugins,cn=con
 fig
CreateTimestamp: 20150320220124Z
ModifyTimestamp: 20150320220124Z

dn: nis-domain=domain.edu+nis-map=netgroup,cn=NIS
Server,cn=plugins,cn=config
CreateTimestamp: 20150320220124Z
ModifyTimestamp: 20150320220124Z

dn: nis-domain=domain.edu+nis-map=netid.byname,cn=NIS
Server,cn=plugins,cn=con
 fig
CreateTimestamp: 20150320220124Z
ModifyTimestamp: 20150320220124Z

dn: nis-domain=domain.edu+nis-map=passwd.byname,cn=NIS
Server,cn=plugins,cn=co
 nfig
CreateTimestamp: 20150320220124Z
ModifyTimestamp: 20150320220124Z

dn: nis-domain=domain.edu+nis-map=passwd.byuid,cn=NIS
Server,cn=plugins,cn=con
 fig
CreateTimestamp: 20150320220124Z
ModifyTimestamp: 20150320220124Z


All the maps are listed from what I can tell. passwd is the one that is not
working as expected. Autofs maps are working all right on nis clients.

On Mon, Jan 11, 2016 at 4:21 PM, Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On Mon, 11 Jan 2016, Prasun Gera wrote:
>
>> I upgraded ipa to 4.2 on my rhel 7.2 servers a few weeks ago. One of the
>> users reported that he is not able to log in to certain systems any more.
>> It turns out that there is some change in behaviour w.r.t NIS clients
>> after
>> this upgrade. I see that his username is not visible in "ypcat passwd" on
>> the old clients that are using NIS. This user was added natively through
>> ipa. The old users that were migrated from NIS still work as expected on
>> the NIS clients. I can also confirm that if I add a new user now in ipa,
>> it
>> is not visible in NIS maps. Until we phase out the NIS clients completely,
>> I would like all users to be able to log into them. This used to be the
>> case, but a recent update seems to have changed that. I don't know if this
>> is intentional. How do i revert to the old behaviour ?
>>
> Do you see all the maps configured?
>
> # ldapsearch  -LLL -H $(cat /etc/ipa/default.conf | grep ldap_uri|cut -d=
> -f2) -b cn=config '(nis-domain=*)' dn CreateTimestamp ModifyTimestamp
>
> We have a bug in the upgrade script that was fixed this morning
> https://www.redhat.com/archives/freeipa-devel/2016-January/msg00154.html
>
> --
> / Alexander Bokovoy
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] IPA users not visible in NIS passwd map

[Prasun Gera]

I upgraded ipa to 4.2 on my rhel 7.2 servers a few weeks ago. One of the
users reported that he is not able to log in to certain systems any more.
It turns out that there is some change in behaviour w.r.t NIS clients after
this upgrade. I see that his username is not visible in "ypcat passwd" on
the old clients that are using NIS. This user was added natively through
ipa. The old users that were migrated from NIS still work as expected on
the NIS clients. I can also confirm that if I add a new user now in ipa, it
is not visible in NIS maps. Until we phase out the NIS clients completely,
I would like all users to be able to log into them. This used to be the
case, but a recent update seems to have changed that. I don't know if this
is intentional. How do i revert to the old behaviour ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] IPA, autofs, kerberos

[Prasun Gera]

I would like to understand this better too. I'm not using kerberized NFS.
I'm using regular nfs for user home dirs as well as other mount points,
which used to work quite well with autofs + NIS. For the most part it works
fine with ipa too. However, I have occasionally faced problems with autofs
not working well on clients. In such cases, the only thing that has worked
is calling the ipa-automount uninstall script, and reinstalling it. Is this
indicative of stale sss cache values ?

On Tue, Jan 5, 2016 at 12:37 AM, Rob Crittenden  wrote:

> Cal Sawyer wrote:
> > Hi
> >
> > After getting autofs working using automountmaps in IPA, i've discovered
> > that upon rebooting a client i have no automounts.  If i ssh into the
> > client and obtain a ticket as admin, after restarting autofs (as root),
> > I can once again see access automounted directories.  Until then, user
> > logins which depend on network home mount consistently fail
> >
> > Question is, how can this be made automatic on reboot?
>
> Credentials are needed to do the mounts so it depends on what
> credentials you want/need to use for that. What mounts are these that
> require Kerberos, home directories or something else?
>
> GSS-Proxy can do this unattended,
> https://fedorahosted.org/gss-proxy/wiki/NFS
>
> rob
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] yum update today broke ipa

[Prasun Gera]

Before I try this on the actual node, would it be better to roll back the
last yum transaction ? I want to do whatever is safer.

On Wed, Dec 9, 2015 at 8:14 AM, Martin Basti <mba...@redhat.com> wrote:

>
>
> On 09.12.2015 16:32, Prasun Gera wrote:
>
> Ran yum update today. Pulled in
> <https://rhn.redhat.com/errata/RHBA-2015-2562.html>
> https://rhn.redhat.com/errata/RHBA-2015-2562.html.
>
> Seeing this error:
>
> 2015-12-09T15:21:02Z DEBUG The ipa-server-upgrade command failed,
> exception: ScriptError: ("Unable to execute IPA upgrade: data are in newer
> version than IPA (data version '4.2.0-15.el7', IPA version
> '4.2.0-15.el7_2.3')", 1)
> 2015-12-09T15:21:02Z ERROR ("Unable to execute IPA upgrade: data are in
> newer version than IPA (data version '4.2.0-15.el7', IPA version
> '4.2.0-15.el7_2.3')", 1)
> "/var/log/ipaupgrade.log" 54696L, 5389464C
>
> ipactl won't start now. Luckily, I ran the update only on one replica. The
> other node is still running.
>
>
> Hello, this is not good, something terrible wrong happened with parsing
> versions.
>
> You can run upgrade with ipa-server-upgrade --skip-version-check or --force
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] yum update today broke ipa

[Prasun Gera]

Thanks! That worked. The command passed, and I don't see any other odd
behaviour yet. I'll wait for a new fixed errata before upgrading the other
node. That should be OK right ? i.e. Running replicas on slightly different
versions.

On Wed, Dec 9, 2015 at 8:22 AM, Martin Basti <mba...@redhat.com> wrote:

> Run upgrade manually, this is just error in checking function, obviously
> 4.2.0-15.el7_2.3 is never than 4.2.0-15.el7
>
>
> On 09.12.2015 17:21, Prasun Gera wrote:
>
> Before I try this on the actual node, would it be better to roll back the
> last yum transaction ? I want to do whatever is safer.
>
> On Wed, Dec 9, 2015 at 8:14 AM, Martin Basti <mba...@redhat.com> wrote:
>
>>
>>
>> On 09.12.2015 16:32, Prasun Gera wrote:
>>
>> Ran yum update today. Pulled in
>> <https://rhn.redhat.com/errata/RHBA-2015-2562.html>
>> https://rhn.redhat.com/errata/RHBA-2015-2562.html.
>>
>> Seeing this error:
>>
>> 2015-12-09T15:21:02Z DEBUG The ipa-server-upgrade command failed,
>> exception: ScriptError: ("Unable to execute IPA upgrade: data are in newer
>> version than IPA (data version '4.2.0-15.el7', IPA version
>> '4.2.0-15.el7_2.3')", 1)
>> 2015-12-09T15:21:02Z ERROR ("Unable to execute IPA upgrade: data are in
>> newer version than IPA (data version '4.2.0-15.el7', IPA version
>> '4.2.0-15.el7_2.3')", 1)
>> "/var/log/ipaupgrade.log" 54696L, 5389464C
>>
>> ipactl won't start now. Luckily, I ran the update only on one replica.
>> The other node is still running.
>>
>>
>> Hello, this is not good, something terrible wrong happened with parsing
>> versions.
>>
>> You can run upgrade with ipa-server-upgrade --skip-version-check or
>> --force
>>
>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] yum update today broke ipa

[Prasun Gera]

Ran yum update today. Pulled in
https://rhn.redhat.com/errata/RHBA-2015-2562.html.

Seeing this error:

2015-12-09T15:21:02Z DEBUG The ipa-server-upgrade command failed,
exception: ScriptError: ("Unable to execute IPA upgrade: data are in newer
version than IPA (data version '4.2.0-15.el7', IPA version
'4.2.0-15.el7_2.3')", 1)
2015-12-09T15:21:02Z ERROR ("Unable to execute IPA upgrade: data are in
newer version than IPA (data version '4.2.0-15.el7', IPA version
'4.2.0-15.el7_2.3')", 1)
"/var/log/ipaupgrade.log" 54696L, 5389464C

ipactl won't start now. Luckily, I ran the update only on one replica. The
other node is still running.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA and LetsEncrypt Question

[Prasun Gera]

Have a look at a recent thread that I had started. You might be able to do
it manually for http/ldap certs. However, there were some issues which I
haven't figured out yet. You might have better luck. Anyone should be able
to try it out given that LE enters public beta in a couple of days.

On Mon, Nov 30, 2015 at 4:46 AM, Alexander Bokovoy 
wrote:

> On Mon, 30 Nov 2015, Günther J. Niederwimmer wrote:
>
>> Hello ,
>>
>> I have the question, know any from the FreeIPA "Gurus" ;-), are the new
>> upcoming LetsEncrypt Certificates compatible and working with FreeIPA?
>>
> We have plans to support issuing certificates via Let's Encrypt.
>
> However, right now Let's encrypt only issues server certificates, not
> CA roots, so you cannot use them to bootstrap IPA CA.
> --
> / Alexander Bokovoy
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

I'll try this on an aws instance and report. Some googling also suggests
that the additional step of "pk12util -i ipa.example.com.p12 -d
/etc/httpd/alias" is needed, which is similar to what you suggested. A few
more questions:
1) How would renewals work ? the pem files can be renewed on expiration
from LE's client. Would I need to run the exact same steps every time ?
2) Do expired ones need to be removed from the db in some way before
renewed ones can be added ?
3) If httpd's certs expire, it won't affect any other functionality apart
from the webui right ? Are there any other side effects ? I won't be using
this for ldap certs.
4) How would I revert to IPA signed certs with automatic renewal if I want
to ? i.e. Reverting to stock configuration


On Wed, Nov 11, 2015 at 8:33 AM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Fraser Tweedale wrote:
>
>> On Tue, Nov 10, 2015 at 08:30:47PM -0800, Prasun Gera wrote:
>>
>>> You are right in that the fullchain.pem doesn't have the root
>>> certificate.
>>> I ran "openssl x509 -in chain.pem -noout -text", and saw that it
>>> had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and
>>> Subject:
>>> C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
>>> certificate for DST Root CA X3 from
>>> https://www.identrust.com/certificates/trustid/root-download-x3.html,
>>> which
>>> is self signed from what I can tell. The issuer and the subject are the
>>> same. I added that to the fullchain, and the command seemed to work.
>>> However, it messed something up, and httpd didn't start after that. httpd
>>> error log had "Unable to verify certificate 'Signing-Cert'. Add
>>> "NSSEnforceValidCerts off" to nss.conf so the server can start until the
>>> problem can be resolved ". I added that to nss.conf, and ipactl started
>>> successfully after that. However, the webui hadn't configured the
>>> certificates properly. At this point, I just restored my backups
>>> of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
>>> where things were earlier. I think it would be better to do these
>>> experiments on a test bed first.
>>>
>>> I am at a loss, and must have missed something.  The purpose of this
>> command is to be able to install 3rd party certificates, yet the
>> code is expecting the certs to be signed by the IPA CA?
>>
>> Can someone explain what is going on here?
>>
>
> That isn't the problem. It doesn't require the IPA CA at all. It just
> checks that the root CA which issued the server cert is available (looks
> for subject == issuer). It would appear that something wasn't imported into
> the Apache NSS db.
>
> You'd need to re-run the import and then look at the Apache NSS database
> to ensure that the entire cert chain was imported with the proper trust
> which apparently it wasn't.
>
> # certutil -L -d /etc/httpd/alias
>
> The entire chain should be there, probably with trust like CT,, or C,,.
>
> To fix trust:
>
> # certutil -M -n "" -t CT,, -d /etc/httpd/alias
>
> To add missing certs:
>
> # certutil -A -n "<nickname"> -t CT,, -d /etc/httpd/alias -i -i
> /path/to/pem
>
> Validate the web server cert. Use whatever nickname is appropriate for you:
>
> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias
>
> The more details you have on what you did to fix this the better as that
> can be used to generate a new bug to fix this upstream.
>
> rob
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

No it didn't quite work.

I ran ipa-server-certinstall -w /etc/letsencrypt/live/
example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem

which gives The full certificate chain is not present in
/etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/
example.com/fullchain.pem


On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale <ftwee...@redhat.com>
wrote:

> On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
> > I tried using let's encrypt's certs manually, but I think I'm missing
> > something. Let's encrypt creates the following files : cert.pem
> chain.pem
> >  fullchain.pem  privkey.pem. I was trying to follow
> > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
> but i
> > wasn't able to get it to work. That page says, "The certificate in
> > mysite.crt must be signed by the CA used when installing FreeIPA." Since
> my
> > ipa installation uses the default internal CA, how do I get lets
> encrypt's
> > certs signed by the ipa CA ? Is that the missing step ?
> >
> I do not think that text is correct, in the case of a
> publicy-trusted certificate (i.e. the server cert is chained to a
> trusted issuer).
>
> Just ignore that text and follow the steps.  Does it work?
>
> Cheers,
> Fraser
>
> > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera <prasun.g...@gmail.com>
> wrote:
> >
> > > Thanks for the discussion. If someone can update the documentation with
> > > mozilla style old, intermediate and modern cipher lists for mod_nss,
> that
> > > would be great. Better still would be to add that option to the
> installer
> > > scripts so that you can choose it during installation. Integrating
> that in
> > > the package would also have the added benefit of settings remaining up
> to
> > > date without manual intervention as standards evolve.
> > >
> > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale <ftwee...@redhat.com>
> > > wrote:
> > >
> > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> > >> > Prasun Gera wrote:
> > >> > > Thanks. After the changes, most things seem to be in order. I see
> two
> > >> > > orange flags though:
> > >> > >
> > >> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS
> > >> DANGER* (more
> > >> > > info
> > >> > > <
> > >>
> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
> > >> >)
> > >> >
> > >> > Renegotiation is required for the CA so you need to leave this
> enabled.
> > >> >
> > >> > > Session resumption (caching)*No (IDs assigned but not
> > >> accepted)*
> > >> >
> > >> > I'll need to look at this in more detail. At worst it would slow new
> > >> > connection performance slightly as it means every connection
> requires a
> > >> > full SSL/TLS handshake. I don't think it's a show-stopper.
> > >> >
> > >> Definitely not a show-stopper.  The main reason this is an "orange"
> > >> alert in SSLLabs is because the server is assigning Session IDs but
> > >> then ignoring them; although confusing it is a fairly common default
> > >> behaviour and doesn't cause any issues with compliant client
> > >> implementation
> > >>
> > >> > rob
> > >> >
> > >> > >
> > >> > > Are these relevant/serious ? Can they be mitigated ?
> > >> > >
> > >> > >
> > >> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <
> rcrit...@redhat.com
> > >> > > <mailto:rcrit...@redhat.com>> wrote:
> > >> > >
> > >> > > Prasun Gera wrote:
> > >> > > > Yes, that's what I was planning to do. i.e. Convert cipher
> > >> names from
> > >> > > > SSL to NSS. I wasn't sure about the other settings though.
> Is
> > >> there an
> > >> > > > equivalent NSSHonorCipherOrder ? Is that implicit ?
> Similarly,
> > >> are there
> > >> > > > equivalent configs for HSTS on the mozilla page? Does NSS
> allow
> > >> using
> > >> > > > generated DH parameters instead of standard ones ? For SSL,
> the
> > >> > > > suggested modifica

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

I tried using let's encrypt's certs manually, but I think I'm missing
something. Let's encrypt creates the following files : cert.pem  chain.pem
 fullchain.pem  privkey.pem. I was trying to follow
http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP but i
wasn't able to get it to work. That page says, "The certificate in
mysite.crt must be signed by the CA used when installing FreeIPA." Since my
ipa installation uses the default internal CA, how do I get lets encrypt's
certs signed by the ipa CA ? Is that the missing step ?

On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera <prasun.g...@gmail.com> wrote:

> Thanks for the discussion. If someone can update the documentation with
> mozilla style old, intermediate and modern cipher lists for mod_nss, that
> would be great. Better still would be to add that option to the installer
> scripts so that you can choose it during installation. Integrating that in
> the package would also have the added benefit of settings remaining up to
> date without manual intervention as standards evolve.
>
> On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale <ftwee...@redhat.com>
> wrote:
>
>> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
>> > Prasun Gera wrote:
>> > > Thanks. After the changes, most things seem to be in order. I see two
>> > > orange flags though:
>> > >
>> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS
>> DANGER* (more
>> > > info
>> > > <
>> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
>> >)
>> >
>> > Renegotiation is required for the CA so you need to leave this enabled.
>> >
>> > > Session resumption (caching)*No (IDs assigned but not
>> accepted)*
>> >
>> > I'll need to look at this in more detail. At worst it would slow new
>> > connection performance slightly as it means every connection requires a
>> > full SSL/TLS handshake. I don't think it's a show-stopper.
>> >
>> Definitely not a show-stopper.  The main reason this is an "orange"
>> alert in SSLLabs is because the server is assigning Session IDs but
>> then ignoring them; although confusing it is a fairly common default
>> behaviour and doesn't cause any issues with compliant client
>> implementation
>>
>> > rob
>> >
>> > >
>> > > Are these relevant/serious ? Can they be mitigated ?
>> > >
>> > >
>> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <rcrit...@redhat.com
>> > > <mailto:rcrit...@redhat.com>> wrote:
>> > >
>> > > Prasun Gera wrote:
>> > > > Yes, that's what I was planning to do. i.e. Convert cipher
>> names from
>> > > > SSL to NSS. I wasn't sure about the other settings though. Is
>> there an
>> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly,
>> are there
>> > > > equivalent configs for HSTS on the mozilla page? Does NSS allow
>> using
>> > > > generated DH parameters instead of standard ones ? For SSL, the
>> > > > suggested modification to the config is 'SSLOpenSSLConfCmd
>> DHParameters
>> > > > "{path to dhparams.pem}"' after generating the params.
>> > >
>> > > NSS does not let the user specify cipher order. It uses its own
>> internal
>> > > sorting from strongest to weakest.
>> > >
>> > > HSTS is a header and not dependent upon SSL provider.
>> > >
>> > > mod_nss doesn't support DH ciphers.
>> > >
>> > > rob
>> > >
>> > > >
>> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale <
>> ftwee...@redhat.com <mailto:ftwee...@redhat.com>
>> > > > <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com>>>
>> wrote:
>> > > >
>> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote:
>> > > > > Thanks for the ticket information. I would still be
>> interested in
>> > > > > configuring mod_nss properly (irrespective of whether the
>> certs are ipa
>> > > > > generated or 3rd party). These are the worrying notes
>> from ssllabs test:
>> > > > >
>> > > > > The server supports only older protocols, but not the
>> cur

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale <ftwee...@redhat.com>
wrote:

> On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote:
> > No it didn't quite work.
> >
> > I ran ipa-server-certinstall -w /etc/letsencrypt/live/
> > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem
> >
> > which gives The full certificate chain is not present in
> > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/
> > example.com/fullchain.pem
> >
> It looks like this error is triggered when there is no self-signed
> certificate in the trust chain (fullchain.pem).  Could you confirm
> that this is the case, and if so, could you try appending the root
> certificate to fullchain.pem and trying again?
>
>

I'm sorry, I didn't quite follow. Can you elaborate what I need to append
to what ?

>From let's encrypt's documentation:

cert.pem
Server certificate only.

This is what Apache needs for SSLCertificateFile.

chain.pem
All certificates that need to be served by the browser excluding server
certificate, i.e. root and intermediate certificates only.

This is what Apache needs for SSLCertificateChainFile.

fullchain.pem
All certificates, including server certificate. This is concatenation of
chain.pem and cert.pem.

This is what nginx needs for ssl_certificate.


So fullchain.pem should have all the relevant bits right ? Do you mean I
should append ipa's root cert from /etc/ipa/ca.crt ?





> It may be that ipa-server-certinstall assumes that your server certs
> are signed by the same CA as your IPA CA certificate, which need not
> be the case.
>
> >
> > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale <ftwee...@redhat.com>
> > wrote:
> >
> > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
> > > > I tried using let's encrypt's certs manually, but I think I'm missing
> > > > something. Let's encrypt creates the following files : cert.pem
> > > chain.pem
> > > >  fullchain.pem  privkey.pem. I was trying to follow
> > > >
> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
> > > but i
> > > > wasn't able to get it to work. That page says, "The certificate in
> > > > mysite.crt must be signed by the CA used when installing FreeIPA."
> Since
> > > my
> > > > ipa installation uses the default internal CA, how do I get lets
> > > encrypt's
> > > > certs signed by the ipa CA ? Is that the missing step ?
> > > >
> > > I do not think that text is correct, in the case of a
> > > publicy-trusted certificate (i.e. the server cert is chained to a
> > > trusted issuer).
> > >
> > > Just ignore that text and follow the steps.  Does it work?
> > >
> > > Cheers,
> > > Fraser
> > >
> > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera <prasun.g...@gmail.com>
> > > wrote:
> > > >
> > > > > Thanks for the discussion. If someone can update the documentation
> with
> > > > > mozilla style old, intermediate and modern cipher lists for
> mod_nss,
> > > that
> > > > > would be great. Better still would be to add that option to the
> > > installer
> > > > > scripts so that you can choose it during installation. Integrating
> > > that in
> > > > > the package would also have the added benefit of settings
> remaining up
> > > to
> > > > > date without manual intervention as standards evolve.
> > > > >
> > > > > On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale <
> ftwee...@redhat.com>
> > > > > wrote:
> > > > >
> > > > >> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> > > > >> > Prasun Gera wrote:
> > > > >> > > Thanks. After the changes, most things seem to be in order. I
> see
> > > two
> > > > >> > > orange flags though:
> > > > >> > >
> > > > >> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS
> > > > >> DANGER* (more
> > > > >> > > info
> > > > >> > > <
> > > > >>
> > >
> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
> > > > >> >)
> > > > >> >
> > > > >> > Renegotiation is required for the CA so you need to leave this
> > > enabled.
> > > >

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

You are right in that the fullchain.pem doesn't have the root certificate.
I ran "openssl x509 -in chain.pem -noout -text", and saw that it
had Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3, and Subject:
C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X1. So I got the root
certificate for DST Root CA X3 from
https://www.identrust.com/certificates/trustid/root-download-x3.html, which
is self signed from what I can tell. The issuer and the subject are the
same. I added that to the fullchain, and the command seemed to work.
However, it messed something up, and httpd didn't start after that. httpd
error log had "Unable to verify certificate 'Signing-Cert'. Add
"NSSEnforceValidCerts off" to nss.conf so the server can start until the
problem can be resolved ". I added that to nss.conf, and ipactl started
successfully after that. However, the webui hadn't configured the
certificates properly. At this point, I just restored my backups
of /etc/httpd/conf.d/ and /etc/httpd/alias/, which brought things back to
where things were earlier. I think it would be better to do these
experiments on a test bed first.


On Tue, Nov 10, 2015 at 5:19 PM, Prasun Gera <prasun.g...@gmail.com> wrote:

>
>
> On Tue, Nov 10, 2015 at 5:04 PM, Fraser Tweedale <ftwee...@redhat.com>
> wrote:
>
>> On Tue, Nov 10, 2015 at 03:44:19PM -0800, Prasun Gera wrote:
>> > No it didn't quite work.
>> >
>> > I ran ipa-server-certinstall -w /etc/letsencrypt/live/
>> > example.com/privkey.pem /etc/letsencrypt/live/example.com/fullchain.pem
>> >
>> > which gives The full certificate chain is not present in
>> > /etc/letsencrypt/live/example.com/privkey.pem, /etc/letsencrypt/live/
>> > example.com/fullchain.pem
>> >
>> It looks like this error is triggered when there is no self-signed
>> certificate in the trust chain (fullchain.pem).  Could you confirm
>> that this is the case, and if so, could you try appending the root
>> certificate to fullchain.pem and trying again?
>>
>>
>
> I'm sorry, I didn't quite follow. Can you elaborate what I need to append
> to what ?
>
> From let's encrypt's documentation:
>
> cert.pem
> Server certificate only.
>
> This is what Apache needs for SSLCertificateFile.
>
> chain.pem
> All certificates that need to be served by the browser excluding server
> certificate, i.e. root and intermediate certificates only.
>
> This is what Apache needs for SSLCertificateChainFile.
>
> fullchain.pem
> All certificates, including server certificate. This is concatenation of
> chain.pem and cert.pem.
>
> This is what nginx needs for ssl_certificate.
>
>
> So fullchain.pem should have all the relevant bits right ? Do you mean I
> should append ipa's root cert from /etc/ipa/ca.crt ?
>
>
>
>
>
>> It may be that ipa-server-certinstall assumes that your server certs
>> are signed by the same CA as your IPA CA certificate, which need not
>> be the case.
>>
>> >
>> > On Tue, Nov 10, 2015 at 3:31 PM, Fraser Tweedale <ftwee...@redhat.com>
>> > wrote:
>> >
>> > > On Tue, Nov 10, 2015 at 03:12:04PM -0800, Prasun Gera wrote:
>> > > > I tried using let's encrypt's certs manually, but I think I'm
>> missing
>> > > > something. Let's encrypt creates the following files : cert.pem
>> > > chain.pem
>> > > >  fullchain.pem  privkey.pem. I was trying to follow
>> > > >
>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
>> > > but i
>> > > > wasn't able to get it to work. That page says, "The certificate in
>> > > > mysite.crt must be signed by the CA used when installing FreeIPA."
>> Since
>> > > my
>> > > > ipa installation uses the default internal CA, how do I get lets
>> > > encrypt's
>> > > > certs signed by the ipa CA ? Is that the missing step ?
>> > > >
>> > > I do not think that text is correct, in the case of a
>> > > publicy-trusted certificate (i.e. the server cert is chained to a
>> > > trusted issuer).
>> > >
>> > > Just ignore that text and follow the steps.  Does it work?
>> > >
>> > > Cheers,
>> > > Fraser
>> > >
>> > > > On Sat, Nov 7, 2015 at 9:15 PM, Prasun Gera <prasun.g...@gmail.com>
>> > > wrote:
>> > > >
>> > > > > Thanks for the discussion. If someone can update the
>> documentation with
>> > > > > mozilla style old, intermediate an

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

Thanks for the discussion. If someone can update the documentation with
mozilla style old, intermediate and modern cipher lists for mod_nss, that
would be great. Better still would be to add that option to the installer
scripts so that you can choose it during installation. Integrating that in
the package would also have the added benefit of settings remaining up to
date without manual intervention as standards evolve.

On Thu, Nov 5, 2015 at 9:23 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:

> On Thu, Nov 05, 2015 at 11:52:32PM -0500, Rob Crittenden wrote:
> > Prasun Gera wrote:
> > > Thanks. After the changes, most things seem to be in order. I see two
> > > orange flags though:
> > >
> > > Secure Client-Initiated Renegotiation   *Supported*   *DoS DANGER*
> (more
> > > info
> > > <
> https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
> >)
> >
> > Renegotiation is required for the CA so you need to leave this enabled.
> >
> > > Session resumption (caching)*No (IDs assigned but not
> accepted)*
> >
> > I'll need to look at this in more detail. At worst it would slow new
> > connection performance slightly as it means every connection requires a
> > full SSL/TLS handshake. I don't think it's a show-stopper.
> >
> Definitely not a show-stopper.  The main reason this is an "orange"
> alert in SSLLabs is because the server is assigning Session IDs but
> then ignoring them; although confusing it is a fairly common default
> behaviour and doesn't cause any issues with compliant client
> implementation
>
> > rob
> >
> > >
> > > Are these relevant/serious ? Can they be mitigated ?
> > >
> > >
> > > On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <rcrit...@redhat.com
> > > <mailto:rcrit...@redhat.com>> wrote:
> > >
> > > Prasun Gera wrote:
> > > > Yes, that's what I was planning to do. i.e. Convert cipher names
> from
> > > > SSL to NSS. I wasn't sure about the other settings though. Is
> there an
> > > > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly,
> are there
> > > > equivalent configs for HSTS on the mozilla page? Does NSS allow
> using
> > > > generated DH parameters instead of standard ones ? For SSL, the
> > > > suggested modification to the config is 'SSLOpenSSLConfCmd
> DHParameters
> > > > "{path to dhparams.pem}"' after generating the params.
> > >
> > > NSS does not let the user specify cipher order. It uses its own
> internal
> > > sorting from strongest to weakest.
> > >
> > > HSTS is a header and not dependent upon SSL provider.
> > >
> > > mod_nss doesn't support DH ciphers.
> > >
> > > rob
> > >
> > > >
> > > > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale <
> ftwee...@redhat.com <mailto:ftwee...@redhat.com>
> > > > <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com>>>
> wrote:
> > > >
> > > > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote:
> > > > > Thanks for the ticket information. I would still be
> interested in
> > > > > configuring mod_nss properly (irrespective of whether the
> certs are ipa
> > > > > generated or 3rd party). These are the worrying notes from
> ssllabs test:
> > > > >
> > > > > The server supports only older protocols, but not the
> current best TLS 1.2.
> > > > > Grade capped to C.
> > > > > This server accepts the RC4 cipher, which is weak. Grade
> capped to B.
> > > > > The server does not support Forward Secrecy with the
> reference browsers.
> > > > >
> > > > Use the "Modern" cipher suite[1] recommended by Mozilla as a
> > > >     starting point.  See also the "Cipher names correspondence
> table" on
> > > > the same page for translating it to cipher names understood
> by NSS
> > > > to construct a valid setting for the `NSSCipherSuite'
> directive.
> > > >
> > > > [1]
> > > >
> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
> > > >
> > > > Cheers,
> > > > Fraser
> &

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

Yes, that's what I was planning to do. i.e. Convert cipher names from SSL
to NSS. I wasn't sure about the other settings though. Is there an
equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, are there
equivalent configs for HSTS on the mozilla page? Does NSS allow using
generated DH parameters instead of standard ones ? For SSL, the suggested
modification to the config is 'SSLOpenSSLConfCmd DHParameters "{path to
dhparams.pem}"' after generating the params.

On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale <ftwee...@redhat.com> wrote:

> On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote:
> > Thanks for the ticket information. I would still be interested in
> > configuring mod_nss properly (irrespective of whether the certs are ipa
> > generated or 3rd party). These are the worrying notes from ssllabs test:
> >
> > The server supports only older protocols, but not the current best TLS
> 1.2.
> > Grade capped to C.
> > This server accepts the RC4 cipher, which is weak. Grade capped to B.
> > The server does not support Forward Secrecy with the reference browsers.
> >
> Use the "Modern" cipher suite[1] recommended by Mozilla as a
> starting point.  See also the "Cipher names correspondence table" on
> the same page for translating it to cipher names understood by NSS
> to construct a valid setting for the `NSSCipherSuite' directive.
>
> [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
>
> Cheers,
> Fraser
>
> >
> > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale <ftwee...@redhat.com>
> wrote:
> >
> > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote:
> > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible
> publicly.
> > > I'm
> > > > using a stock configuration which uses the certs signed by ipa's CA
> for
> > > the
> > > > webui. This is mostly for convenience since it manages renewals
> > > seamlessly.
> > > > This, however, requires users to add the CA as trusted to their
> > > browsers. A
> > > > promising alternative to this is https://letsencrypt.org/, which
> issues
> > > > browser trusted certs, and will manage auto renewals too (in the
> future).
> > > > As a feature request, it would be nice to have closer integration
> between
> > > > ipa and the letsencrypt client which would make managing certs
> simple.
> > > I'm
> > > > about to set this up manually right now using the external ssl certs
> > > guide.
> > > >
> > > Let's Encrypt is on our radar.  I like the idea of being able to
> > > install FreeIPA with publicly-trusted certs for HTTP and LDAP from
> > > the beginning.  This would require some work in ipa-server-install
> > > in addition to certmonger support and a good, stable Let's Encrypt /
> > > ACME client implementation for Apache on Fedora.
> > >
> > > Installing publicly-trusted HTTP / LDAP certs is a common activity
> > > so I filed a ticket: https://fedorahosted.org/freeipa/ticket/5431
> > >
> > > Cheers,
> > > Fraser
> > >
> > > > Secondly, since the webui uses mod_nss, how would one set it up to
> prefer
> > > > security over compatibility with older clients ? The vast majority of
> > > > documentation online (for eg.
> > > > https://mozilla.github.io/server-side-tls/ssl-config-generator/) is
> > > about
> > > > mod_ssl and I think the configuration doesn't transfer directly to
> > > mod_nss.
> > > > Since this is the only web facing component, I would like to set it
> up to
> > > > use stringent requirements. Right now, a test on
> > > > https://www.ssllabs.com/ssltest/ and
> https://weakdh.org/sysadmin.html
> > > > identifies
> > > > several issues. Since these things are not really my area of
> expertise, I
> > > > would like some documentation regarding this. Also, would manually
> > > > modifying any of the config files be overwritten by a yum update ?
> > >
> > > > --
> > > > Manage your subscription for the Freeipa-users mailing list:
> > > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > > > Go to http://freeipa.org for more info on the project
> > >
> > >
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

Thanks. After the changes, most things seem to be in order. I see two
orange flags though:

Secure Client-Initiated Renegotiation*Supported*   *DoS DANGER* (more info
<https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks>
)Session resumption (caching)*No (IDs assigned but not accepted)*
Are these relevant/serious ? Can they be mitigated ?


On Thu, Nov 5, 2015 at 6:51 AM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Prasun Gera wrote:
> > Yes, that's what I was planning to do. i.e. Convert cipher names from
> > SSL to NSS. I wasn't sure about the other settings though. Is there an
> > equivalent NSSHonorCipherOrder ? Is that implicit ? Similarly, are there
> > equivalent configs for HSTS on the mozilla page? Does NSS allow using
> > generated DH parameters instead of standard ones ? For SSL, the
> > suggested modification to the config is 'SSLOpenSSLConfCmd DHParameters
> > "{path to dhparams.pem}"' after generating the params.
>
> NSS does not let the user specify cipher order. It uses its own internal
> sorting from strongest to weakest.
>
> HSTS is a header and not dependent upon SSL provider.
>
> mod_nss doesn't support DH ciphers.
>
> rob
>
> >
> > On Wed, Nov 4, 2015 at 8:21 PM, Fraser Tweedale <ftwee...@redhat.com
> > <mailto:ftwee...@redhat.com>> wrote:
> >
> > On Wed, Nov 04, 2015 at 05:03:29PM -0800, Prasun Gera wrote:
> > > Thanks for the ticket information. I would still be interested in
> > > configuring mod_nss properly (irrespective of whether the certs
> are ipa
> > > generated or 3rd party). These are the worrying notes from ssllabs
> test:
> > >
> > > The server supports only older protocols, but not the current best
> TLS 1.2.
> > > Grade capped to C.
> > > This server accepts the RC4 cipher, which is weak. Grade capped to
> B.
> > > The server does not support Forward Secrecy with the reference
> browsers.
> > >
> > Use the "Modern" cipher suite[1] recommended by Mozilla as a
> > starting point.  See also the "Cipher names correspondence table" on
> > the same page for translating it to cipher names understood by NSS
> > to construct a valid setting for the `NSSCipherSuite' directive.
> >
> > [1]
> >
> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
> >
> > Cheers,
> > Fraser
> >
> > >
> > > On Wed, Nov 4, 2015 at 4:44 PM, Fraser Tweedale
> > <ftwee...@redhat.com <mailto:ftwee...@redhat.com>> wrote:
> > >
> > > > On Wed, Nov 04, 2015 at 03:20:22PM -0800, Prasun Gera wrote:
> > > > > I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible
> > publicly.
> > > > I'm
> > > > > using a stock configuration which uses the certs signed by
> > ipa's CA for
> > > > the
> > > > > webui. This is mostly for convenience since it manages renewals
> > > > seamlessly.
> > > > > This, however, requires users to add the CA as trusted to their
> > > > browsers. A
> > > > > promising alternative to this is https://letsencrypt.org/,
> > which issues
> > > > > browser trusted certs, and will manage auto renewals too (in
> > the future).
> > > > > As a feature request, it would be nice to have closer
> > integration between
> > > > > ipa and the letsencrypt client which would make managing certs
> > simple.
> > > > I'm
> > > > > about to set this up manually right now using the external ssl
> > certs
> > > > guide.
> > > > >
> > > > Let's Encrypt is on our radar.  I like the idea of being able to
> > > > install FreeIPA with publicly-trusted certs for HTTP and LDAP
> from
> > > > the beginning.  This would require some work in
> ipa-server-install
> > > > in addition to certmonger support and a good, stable Let's
> Encrypt /
> > > > ACME client implementation for Apache on Fedora.
> > > >
> > > > Installing publicly-trusted HTTP / LDAP certs is a common
> activity
> > > > so I filed a ticket:
> https://fedorahosted.org/freeipa/ticket/5431
> > > >
> > > > Cheers,
> > > > Fraser
> > > >
> >  

[Freeipa-users] let's encrypt integration and best practices for mod_nss/mod_ssl

[Prasun Gera]

I'm using idm (4.1.x) on a RHEL 7.1 with the webui accessible publicly. I'm
using a stock configuration which uses the certs signed by ipa's CA for the
webui. This is mostly for convenience since it manages renewals seamlessly.
This, however, requires users to add the CA as trusted to their browsers. A
promising alternative to this is https://letsencrypt.org/, which issues
browser trusted certs, and will manage auto renewals too (in the future).
As a feature request, it would be nice to have closer integration between
ipa and the letsencrypt client which would make managing certs simple. I'm
about to set this up manually right now using the external ssl certs guide.

Secondly, since the webui uses mod_nss, how would one set it up to prefer
security over compatibility with older clients ? The vast majority of
documentation online (for eg.
https://mozilla.github.io/server-side-tls/ssl-config-generator/) is about
mod_ssl and I think the configuration doesn't transfer directly to mod_nss.
Since this is the only web facing component, I would like to set it up to
use stringent requirements. Right now, a test on
https://www.ssllabs.com/ssltest/ and https://weakdh.org/sysadmin.html
identifies
several issues. Since these things are not really my area of expertise, I
would like some documentation regarding this. Also, would manually
modifying any of the config files be overwritten by a yum update ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] enabling selinux on ipa server

[Prasun Gera]

I'm using the default version on RHEL7. I think that's 4.1.x. This was a
replica server. Selinux was disabled when the replica was installed. I
enabled in in enforcing mode yesterday, and saw those issues. On the main
server, selinux is (and has always been) enabled in enforcing mode, and
everything works fine. I also compared the bools between the main server
and the replica, and the bools on the main server were correctly setup,
whereas the ones you mentioned weren't set up properly on the replica. So
from the limited information I have at hand, I think that setting up a
replica server in the selinux disabled state didn't set up the selinux
related stuff properly, which manifested later when i set it to enforcing
mode.

On Sat, Oct 24, 2015 at 9:13 PM, Rob Crittenden <rcrit...@redhat.com> wrote:

> Prasun Gera wrote:
> > I've done that now in addition to the few fixes that I made manually
> > earlier. These were the messages:
> > SELinux is preventing /usr/sbin/ns-slapd from write access on the file
> > ldap_988
> > SELinux is preventing /usr/sbin/httpd from read access on the lnk_file
> > /etc/httpd/logs
> > And a few others. I also had to do sudo setsebool -P httpd_manage_ipa 1
>
> It would help to know what version you're using.
>
> The installer will skip setting the booleans if SELinux disabled. The
> installer won't disable SELinux itself.
>
> A default install will enable these booleans:
>
> httpd_can_network_connect
> httpd_manage_ipa
> httpd_run_ipa
>
> AD trust will enable samba_portmapper
>
> rob
>
> >
> > On Sat, Oct 24, 2015 at 10:51 AM, Lukas Slebodnik <lsleb...@redhat.com
> > <mailto:lsleb...@redhat.com>> wrote:
> >
> > On (23/10/15 20:57), Prasun Gera wrote:
> > >selinux was disabled for some reason when the ipa server(replica)
> was
> > >installed. I enabled it, and see that there are a lot of selinux
> > related
> > >permissions problems in syslog. Is this a known issue ? I tried
> > fixing some
> > >of them manually, but i would like a better approach.
> > FreeIPA should work fine with SELinux in enforcing mode.
> >
> > I would recommend to restore SELinux context of files on that
> machine.
> >
> > restorecon -Rv /
> >
> > LS
> >
> >
> >
> >
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] enabling selinux on ipa server

[Prasun Gera]

I've done that now in addition to the few fixes that I made manually
earlier. These were the messages:
SELinux is preventing /usr/sbin/ns-slapd from write access on the file
ldap_988
SELinux is preventing /usr/sbin/httpd from read access on the lnk_file
/etc/httpd/logs
And a few others. I also had to do sudo setsebool -P httpd_manage_ipa 1

On Sat, Oct 24, 2015 at 10:51 AM, Lukas Slebodnik <lsleb...@redhat.com>
wrote:

> On (23/10/15 20:57), Prasun Gera wrote:
> >selinux was disabled for some reason when the ipa server(replica) was
> >installed. I enabled it, and see that there are a lot of selinux related
> >permissions problems in syslog. Is this a known issue ? I tried fixing
> some
> >of them manually, but i would like a better approach.
> FreeIPA should work fine with SELinux in enforcing mode.
>
> I would recommend to restore SELinux context of files on that machine.
>
> restorecon -Rv /
>
> LS
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] enabling selinux on ipa server

[Prasun Gera]

selinux was disabled for some reason when the ipa server(replica) was
installed. I enabled it, and see that there are a lot of selinux related
permissions problems in syslog. Is this a known issue ? I tried fixing some
of them manually, but i would like a better approach.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] admin loses access?

[Prasun Gera]

I was facing similar issues, and ended up changing the username from admin
to something else since admin is a common name in brute force ssh attacks.
It was getting locked out in spite of using fail2ban. I guess fail2ban can
be tweaked to block the host before ipa blocks the admin account, but I
didn't bother doing that. Changing the username seemed easier.

On Mon, Oct 5, 2015 at 8:19 AM, Rob Crittenden  wrote:

> Janelle wrote:
> > On 10/5/15 7:39 AM, Rob Crittenden wrote:
> >> Torsten Harenberg wrote:
> >>> Hi Janelle,
> >>>
> >>> Am 04.10.2015 um 19:25 schrieb Janelle:
>  Just wondering if anyone knows why this happens from time to time on
>  servers:
> 
>  $ kinit admin
>  kinit: Clients credentials have been revoked while getting initial
>  credentials
> 
>  there are no failed logins to the admin account - not even any login
>  attempts, so it is not like someone is getting the account locked out.
>  Just curious if anyone else has seen in. With 16 masters, it occurs
>  randomly on some hosts, but eventually clears either on its own or
> with
>  a restart of IPA. However, I just restarted IPA on this server and
>  after
>  about 2-3 minutes it works again.
> 
> >>> I am seeing the same, see my mail "kinit admin not working anymore
> >>> (LOCKED_OUT: Clients credentials have been revoked)" from 03-SEPT.
> >>> Actually, wasn't it you who wanted to open a ticket?
> >>>
> >>> Have a nice evening,
> >>>
> >>>Torsten
> >>>
> >> When you see this run `ipa user-status admin` and `ipa pwpolicy-show
> >> --user=admin` and provide that so we can potentially see what is going
> >> on.
> >>
> >> rob
> >>
> > I am curious -- if you have 16 masters, but this only happens once in
> > awhile on 1 or 2 servers, how does the pwpolicy fit in? I am trying to
> > understand the thinking of where you are going?? I will for sure do this
> > the next time it happens, but I want to understand logic?
>
> Lockout is per-master because the failed auth count and successful login
> date is not replicated due to performance issues.
>
> The user-status command will collect the lockout attributes from each
> server, but it doesn't do the calculations, so the pwpolicy is needed as
> well in order to figure out whether on a given master the user is locked
> out.
>
> rob
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ntpd frequency error xxx PPM exceeds tolerance 500 PPM

[Prasun Gera]

Has this got anything to do with ipa ? The messages started only recently,
which makes me think that it's not a hardware issue. There were only two
notable changes to this system recently. The hdd had to be replaced, and a
replica was set up. Could either have any part to play ?

On Thu, Sep 10, 2015 at 6:03 AM, Prasun Gera <prasun.g...@gmail.com> wrote:

> The hardware is not very old (ivybridge). The entries appear every few
> minutes in the log. The /etc/ntp.conf has not been modified manually. It
> lists 3 servers - 0.rhel.pool.ntp.org, 1 and 2. At the end, there are
> also a couple of additional local servers with the comment added by
> /sbin/dhclient-script. The replica on the same network with an identical
> ntp.conf file doesn't have these messages in the current log. However, if I
> go back to a week, I see similar messages there too.  The ping to public
> ntp servers varies from to a few ms to ~50 ms. The ping to local servers is
> under 1 ms. I followed steps from the first link (ntpd -qg), and the
> messages have stopped for now, but I suspect that they will reappear later.
> That's what happened last time I tried that solution. This is the output
> from ntpq -pn on the master:
>
>  remote   refid  st t when poll reach   delay   offset
>  jitter
>
> ==
> +38.229.71.1 204.123.2.5  2 u   39   64  377   44.300  -1311.8
> 7.668
> +64.6.144.6  128.252.19.1 2 u   25   64  377   38.184  -1327.6
>  12.615
> -129.250.35.251  200.98.196.212   2 u   30   64  377   14.649  -1318.8
> 7.079
>  127.127.1.0 .LOCL.  10 l-   6400.0000.000
> 0.000
> *localnetip1  localnetref1  2 u   55   64  3770.349  -1316.0   8.264
> -localnetip2  localnetref23 u   64   64  3770.459  -1309.6  10.516
>
>
> On Thu, Sep 10, 2015 at 5:27 AM, Andrew Holway <andrew.hol...@gmail.com>
> wrote:
>
>> If could be the server is trying to access the time server over a heavily
>> congested network which could cause these types of problems.
>>
>>
>> How old is the hardware?
>> How often to these entries appear in the log?
>> What is the ping / traceroute to the time server you are using?
>> Are there any other machines on the same local network that are using
>> this timeserver? Do they have problems?
>>
>>
>>
>>
>> On 10 September 2015 at 14:18, Prasun Gera <prasun.g...@gmail.com> wrote:
>>
>>> So I did a bit of googling and tinker panic 0 only makes sense for
>>> virtual machines. Is there any way to confirm if it is indeed a hardware
>>> issue ?
>>>
>>> On Thu, Sep 10, 2015 at 5:16 AM, Andrew Holway <andrew.hol...@gmail.com>
>>> wrote:
>>>
>>>> Thats odd. You would normally not need it on bare metal. It could be
>>>> broken hardware.
>>>>
>>>> On 10 September 2015 at 14:05, Prasun Gera <prasun.g...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks. I'm not virtualizing though. Should I still add it ?
>>>>>
>>>>> On Thu, Sep 10, 2015 at 5:02 AM, Andrew Holway <
>>>>> andrew.hol...@gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I assume you are virtualising.
>>>>>>
>>>>>> Try adding "tinker panic 0" to /etc/ntp.conf.
>>>>>>
>>>>>> It should make it tolerant to heavily drifting virtual clocks.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Andrew
>>>>>>
>>>>>> On 10 September 2015 at 13:46, Prasun Gera <prasun.g...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> OS: RHEL 7.1 w IDM
>>>>>>>
>>>>>>> I'm seeing these messages in my master's log messages. I don't know
>>>>>>> if it's related, but I think I started seeing them after I set up a
>>>>>>> replica. Everything seems to be working fine, but I'm worried that 
>>>>>>> things
>>>>>>> will break if delta grows beyond a point. I tried steps in
>>>>>>> https://access.redhat.com/solutions/35640, but it didn't really
>>>>>>> help. The messages still appear regularly in the log.
>>>>>>>
>>>>>>> --
>>>>>>> Manage your subscription for the Freeipa-users mailing list:
>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>>> Go to http://freeipa.org for more info on the project
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] ntpd frequency error xxx PPM exceeds tolerance 500 PPM

[Prasun Gera]

OS: RHEL 7.1 w IDM

I'm seeing these messages in my master's log messages. I don't know if it's
related, but I think I started seeing them after I set up a replica.
Everything seems to be working fine, but I'm worried that things will break
if delta grows beyond a point. I tried steps in
https://access.redhat.com/solutions/35640, but it didn't really help. The
messages still appear regularly in the log.
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ntpd frequency error xxx PPM exceeds tolerance 500 PPM

[Prasun Gera]

Thanks. I'm not virtualizing though. Should I still add it ?

On Thu, Sep 10, 2015 at 5:02 AM, Andrew Holway <andrew.hol...@gmail.com>
wrote:

> Hi,
>
> I assume you are virtualising.
>
> Try adding "tinker panic 0" to /etc/ntp.conf.
>
> It should make it tolerant to heavily drifting virtual clocks.
>
> Cheers,
>
> Andrew
>
> On 10 September 2015 at 13:46, Prasun Gera <prasun.g...@gmail.com> wrote:
>
>> OS: RHEL 7.1 w IDM
>>
>> I'm seeing these messages in my master's log messages. I don't know if
>> it's related, but I think I started seeing them after I set up a replica.
>> Everything seems to be working fine, but I'm worried that things will break
>> if delta grows beyond a point. I tried steps in
>> https://access.redhat.com/solutions/35640, but it didn't really help.
>> The messages still appear regularly in the log.
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ntpd frequency error xxx PPM exceeds tolerance 500 PPM

[Prasun Gera]

The hardware is not very old (ivybridge). The entries appear every few
minutes in the log. The /etc/ntp.conf has not been modified manually. It
lists 3 servers - 0.rhel.pool.ntp.org, 1 and 2. At the end, there are also
a couple of additional local servers with the comment added by
/sbin/dhclient-script. The replica on the same network with an identical
ntp.conf file doesn't have these messages in the current log. However, if I
go back to a week, I see similar messages there too.  The ping to public
ntp servers varies from to a few ms to ~50 ms. The ping to local servers is
under 1 ms. I followed steps from the first link (ntpd -qg), and the
messages have stopped for now, but I suspect that they will reappear later.
That's what happened last time I tried that solution. This is the output
from ntpq -pn on the master:

 remote   refid  st t when poll reach   delay   offset
 jitter
==
+38.229.71.1 204.123.2.5  2 u   39   64  377   44.300  -1311.8
7.668
+64.6.144.6  128.252.19.1 2 u   25   64  377   38.184  -1327.6
 12.615
-129.250.35.251  200.98.196.212   2 u   30   64  377   14.649  -1318.8
7.079
 127.127.1.0 .LOCL.  10 l-   6400.0000.000
0.000
*localnetip1  localnetref1  2 u   55   64  3770.349  -1316.0   8.264
-localnetip2  localnetref23 u   64   64  3770.459  -1309.6  10.516


On Thu, Sep 10, 2015 at 5:27 AM, Andrew Holway <andrew.hol...@gmail.com>
wrote:

> If could be the server is trying to access the time server over a heavily
> congested network which could cause these types of problems.
>
>
> How old is the hardware?
> How often to these entries appear in the log?
> What is the ping / traceroute to the time server you are using?
> Are there any other machines on the same local network that are using this
> timeserver? Do they have problems?
>
>
>
>
> On 10 September 2015 at 14:18, Prasun Gera <prasun.g...@gmail.com> wrote:
>
>> So I did a bit of googling and tinker panic 0 only makes sense for
>> virtual machines. Is there any way to confirm if it is indeed a hardware
>> issue ?
>>
>> On Thu, Sep 10, 2015 at 5:16 AM, Andrew Holway <andrew.hol...@gmail.com>
>> wrote:
>>
>>> Thats odd. You would normally not need it on bare metal. It could be
>>> broken hardware.
>>>
>>> On 10 September 2015 at 14:05, Prasun Gera <prasun.g...@gmail.com>
>>> wrote:
>>>
>>>> Thanks. I'm not virtualizing though. Should I still add it ?
>>>>
>>>> On Thu, Sep 10, 2015 at 5:02 AM, Andrew Holway <andrew.hol...@gmail.com
>>>> > wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I assume you are virtualising.
>>>>>
>>>>> Try adding "tinker panic 0" to /etc/ntp.conf.
>>>>>
>>>>> It should make it tolerant to heavily drifting virtual clocks.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Andrew
>>>>>
>>>>> On 10 September 2015 at 13:46, Prasun Gera <prasun.g...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> OS: RHEL 7.1 w IDM
>>>>>>
>>>>>> I'm seeing these messages in my master's log messages. I don't know
>>>>>> if it's related, but I think I started seeing them after I set up a
>>>>>> replica. Everything seems to be working fine, but I'm worried that things
>>>>>> will break if delta grows beyond a point. I tried steps in
>>>>>> https://access.redhat.com/solutions/35640, but it didn't really
>>>>>> help. The messages still appear regularly in the log.
>>>>>>
>>>>>> --
>>>>>> Manage your subscription for the Freeipa-users mailing list:
>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>> Go to http://freeipa.org for more info on the project
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ntpd frequency error xxx PPM exceeds tolerance 500 PPM

[Prasun Gera]

So I did a bit of googling and tinker panic 0 only makes sense for virtual
machines. Is there any way to confirm if it is indeed a hardware issue ?

On Thu, Sep 10, 2015 at 5:16 AM, Andrew Holway <andrew.hol...@gmail.com>
wrote:

> Thats odd. You would normally not need it on bare metal. It could be
> broken hardware.
>
> On 10 September 2015 at 14:05, Prasun Gera <prasun.g...@gmail.com> wrote:
>
>> Thanks. I'm not virtualizing though. Should I still add it ?
>>
>> On Thu, Sep 10, 2015 at 5:02 AM, Andrew Holway <andrew.hol...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I assume you are virtualising.
>>>
>>> Try adding "tinker panic 0" to /etc/ntp.conf.
>>>
>>> It should make it tolerant to heavily drifting virtual clocks.
>>>
>>> Cheers,
>>>
>>> Andrew
>>>
>>> On 10 September 2015 at 13:46, Prasun Gera <prasun.g...@gmail.com>
>>> wrote:
>>>
>>>> OS: RHEL 7.1 w IDM
>>>>
>>>> I'm seeing these messages in my master's log messages. I don't know if
>>>> it's related, but I think I started seeing them after I set up a replica.
>>>> Everything seems to be working fine, but I'm worried that things will break
>>>> if delta grows beyond a point. I tried steps in
>>>> https://access.redhat.com/solutions/35640, but it didn't really help.
>>>> The messages still appear regularly in the log.
>>>>
>>>> --
>>>> Manage your subscription for the Freeipa-users mailing list:
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>> Go to http://freeipa.org for more info on the project
>>>>
>>>
>>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo (sssd) hangs due to ipa install/uninstall scripts

[Prasun Gera]

I have zero confidence in any of the install and uninstall scripts. And
this is on RHEL systems. On unofficial ones like Ubuntu, things are even
more broken. I really like freeipa, but so far even in a smallish lab
environment, it has been a nightmare. I am really tempted to just go back
to NIS. Does anyone have any ideas or proposals for making things more
robust ? At the very least, I think that these sort of modifications to
system files should only happen with package install/removal. Any changes
that ipa's scripts do should be local to ipa's internal state. Better would
be to have an internal ipa database sort of thing which keeps track of what
the current state is so that even if a script dies, which has happened
often, the next attempt reads the database and figures out what happened
earlier.

On Wed, Sep 2, 2015 at 11:32 PM, Jakub Hrozek <jhro...@redhat.com> wrote:

> On Wed, Sep 02, 2015 at 06:30:09PM -0700, Prasun Gera wrote:
> > FYI, I think the culprit (at least one of) is ipa-client-automount
> > --uninstall. This removes sss entirely from nssswitch, not just from the
> > automount section.
>
> Hmm, I haven't tested that but it sounds like a bug.. I would expect
> automount uninstall to touch my passwd or group database..
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo (sssd) hangs due to ipa install/uninstall scripts

[Prasun Gera]

FYI, I think the culprit (at least one of) is ipa-client-automount
--uninstall. This removes sss entirely from nssswitch, not just from the
automount section.

On Tue, Sep 1, 2015 at 11:56 AM, Prasun Gera <prasun.g...@gmail.com> wrote:

> So I've again spent a couple of hours debugging a very similar issue.
> Client install would seemingly pass, but with "Unable to find 'admin' user
> with 'getent passwd admin@domain'!" at the end. And nobody would be able
> to authenticate. The reason was that /etc/nsswitch.conf wasn't updated. sss
> wasn't added to it.  Wading through his thread
> https://www.redhat.com/archives/freeipa-users/2015-March/msg00538.html
> provided some hints. I have no idea why it did that, but as I have
> experienced before, modifying critical system files this way from python
> scripts which don't have proper transnactional support is very dangerous. I
> suspect that this has something to do with a prior failed install or
> uninstall attempt which left it in an inconsistent state. Is it possible to
> move from this backup-modify-restore approach to critical files to
> something more robust which has transnational guarantees ?
>
> On Sat, Jun 27, 2015 at 6:26 AM, Dmitri Pal <d...@redhat.com> wrote:
>
>> On 06/24/2015 04:31 AM, Jakub Hrozek wrote:
>>
>>> On Wed, Jun 24, 2015 at 01:24:37AM -0700, Prasun Gera wrote:
>>>
>>>> Thanks. It's good to know that it is fixed upstream. For discussion
>>>> though,
>>>> are any enhancements planned for dealing with installation/removal of
>>>> ipa ?
>>>>
>>> Not sure, but please file bugs as you see them.
>>>
>>> Yes, please be more specific . The bugs that were mentioned by Jakub are
>> making its way into downstream. If there are any other issues you are
>> concerned about please let us know.
>>
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Director of Engineering for IdM portfolio
>> Red Hat, Inc.
>>
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Users can't login on some systems.

[Prasun Gera]

Did you clear out /var/lib/sss/db between re-installation of the client?
There was a bug which might not have been fixed downstream yet.

On Thu, Aug 20, 2015 at 1:21 PM, Chris Mohler cmoh...@oberlin.edu wrote:

 Hi List,
 I'm still fairly new to this list and administrating FreeIPA.

 I had a very old version of freeipa and had all sorts of odd issues with
 it. I had 47 ubuntu clients attached to the domain.

 I setup a newer freeipa server version: 4.1.4
 I recreated all my user accounts by hand I did not migrate any of them.
 I then removed the 47 clients from the old domain

 #ipa-client-install --uninstall

 Then I reinstalled each client

 #ipa-client-install --domain=cs.oberlin.edu --realm=CS.OBERLIN.EDU -p
 admin -W --hostname `hostname` -N

 it finished without errors on all my systems.

 two of my systems will not let any ipa users login via ssh or the console.
 the rest of them work fine.
 After keying in the password I get the following.

 Permission denied, please try again.

 id (username) shows the UID and GID and Groups correctly.
 getent passwd shows only my local accounts I don't have enumerate on.
 kinit also works.

 *my auth.log shows this*
 pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh
 ruser= rhost=132.162.201.237  user=HIDDEN
 pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh
 ruser= rhost=132.162.201.237 user=HIDDEN
 pam_sss(sshd:auth): received for user : 7 (Authentication failure)

 I know it's the correct password as it works on the other clients.

 *I get this in krb5_child.log*

 [[sssd[krb5_child[10546 [unpack_buffer] (0x0100): cmd [241] uid
 [66133] gid [100] validate [true] enterprise principal [false] offline
 [false] UPN [@CS.OBERLIN.EDU]
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [unpack_buffer]
 (0x0100): ccname: [FILE:/tmp/krb5cc_66133_XX] keytab:
 [/etc/krb5.keytab]
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546
 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME]
 from environment.
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546
 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from
 environment.
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546
 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true]
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_setup_fast]
 (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [
 host/occs.cs.oberlin@cs.oberlin.edu]
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [match_principal]
 (0x1000): Principal matched to the sample (
 host/occs.cs.oberlin@cs.oberlin.edu).
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [check_fast_ccache]
 (0x0200): FAST TGT is still valid.
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400):
 Will perform online auth
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [tgt_req_child]
 (0x1000): Attempting to get a TGT
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [get_and_save_tgt]
 (0x0400): Attempting kinit for realm [CS.OBERLIN.EDU]
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [validate_tgt]
 (0x0400): TGT verified using key for [
 host/occs.cs.oberlin@cs.oberlin.edu].
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [become_user]
 (0x0200): Trying to become user [66133][100].
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [k5c_send_data]
 (0x0200): Received error code 0
 (Tue Aug 18 10:46:28 2015) [[sssd[krb5_child[10546 [main] (0x0400):
 krb5_child completed successfully
 (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [main] (0x0400):
 krb5_child started.
 (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer]
 (0x1000): total buffer size: [127]
 (Tue Aug 18 10:50:20 2015) [[sssd[krb5_child[10616 [unpack_buffer]
 (0x0100): cmd [241] uid [66133] gid [100] validate [true] enterprise
 principal [false] offline [false] UPN [@CS.OBERLIN.EDU]

 *sssd.conf on the broken machine*

 [domain/cs.oberlin.edu]
 debug_level=8
 cache_credentials = True
 krb5_store_password_if_offline = True
 ipa_domain = cs.oberlin.edu
 id_provider = ipa
 auth_provider = ipa
 access_provider = ipa
 ipa_hostname = occs.cs.oberlin.edu
 chpass_provider = ipa
 ipa_server = _srv_, ipa1.cs.oberlin.edu
 ldap_tls_cacert = /etc/ipa/ca.crt
 [sssd]
 services = nss, pam, ssh
 config_file_version = 2
 debug_level=8
 domains = cs.oberlin.edu
 [nss]
 debug_level=8
 [pam]
 debug_level=8
 [sudo]

 [autofs]

 [ssh]
 debug_level=8
 [pac]



 *The broken systems sssd_nss.log *[nss_cmd_getpwnam_search] (0x0400):
 Returning info for user [hid...@cs.oberlin.edu]
 [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input
 [HIDDEN].
 [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'HIDDEN' matched
 without domain, user is HIDDEN
 [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain
 [(null)]
 [sssd[nss]] [nss_cmd_getbynam] (0x0100): 

Re: [Freeipa-users] users- ssh keys self service

[Prasun Gera]

Did you try the */ipa/migration/*  url for migrated users ?

On Fri, Aug 14, 2015 at 3:38 AM, Petr Vobornik pvobo...@redhat.com wrote:

 On 08/13/2015 09:25 PM, Janelle wrote:

 AHA!!!

 The problem is found, but the solution eludes me.
 Any user migrated in compat mode has the problem. NEW users do not.
 Thoughts? Ideas? troubleshooting? What do I need to make visible for
 users to edit their settings?


 How does the migrated user and a new user differ in your environment?

 E.g. do they have different object classes?


 ~J

 On 8/13/15 9:58 AM, Janelle wrote:

 Hi,

 So I still have been unable to find the problem with blank screens for
 users when they login to the gui and can not manage anything other
 than OTP.  Out of the box, vanilla install of FreeOTP on RHEL 7.x and
 using IPA 4.1.4, a user logs in, you see ALL the fields for a split
 second, before they go blank and there is no way to bring them back.
 This is over course frustrating since users can not add their SSH
 keys. They can change there PW, since that is on the ACTION button,
 which remains visible.

 Are there any troubleshooting suggestions for this? I have not
 customized anything.

 Thank you
 ~J




 --
 Petr Vobornik


 --
 Manage your subscription for the Freeipa-users mailing list:
 https://www.redhat.com/mailman/listinfo/freeipa-users
 Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Kerberized NFS and home automount issues

[Prasun Gera]

Where are you trying to create the home directories ? Is your NFS server
the same as the IPA server ? You can only create home directories on the
NFS home server unless the nfs-client sees the export option
no_root_squash. That is not recommended though.

On Thu, Aug 13, 2015 at 9:49 AM, Youenn PIOLET piole...@gmail.com wrote:

 Hi,

 I'm currently trying to configure automount for home directories with
 Kerberized NFSv4.
 I'm  struggling with two issues that may or may not be related:

 1) Can't read my home directory. I have to type kinit manually first on
 each integrated client for this to work. I think it is related to the
 latest versions of sssd on Centos 7 / Fedora 21 (1.12.2-58), ipa of maybe
 nss, a 1 or 2 months outdate centos was working first and got broken after
 an update.

 2) Can't create home directories for new users : Permission denied for
 oddjob-mkhomedir script. I can also experience this as root : can't mkdir
 /home/someuser, permission denied (see my mount chain in freeipa below).
 Related to NFSv4?

 Here is my setup and various information:
 - I'm not using selinux
 - Exports :
 /home.shared *(rw,sec=krb5:krb5i:krb5p)
 - Mount chain :
 * -fstype=nfs4,sec=krb5i,rw,proto=tcp,port=2049,rsize=8192,wsize=8192
 home01.net:/home.shared/
 - Experienced on Centos 7 and Fedora 21
 - FreeIPA server 4.1.4
 - I used ipa-client-automount on clients and server.
 - Same behavior with/without a dedicated service principal on client
 - Some errors in NFS server logs :
 rpc.gssd - WARNING: can't create tcp rpc_clnt to server ipa-server
 for user with uid 0: RPC: Remote system error - No route to host -- at
 different times
 oddjobd: Error
 org.freedesktop.DBus.Error.SELinuxSecurityContextUnknown: Could not
 determine security context for '1:###' -- before oddjob-mkhomedir on new
 user

 Have you got the same problems and did you manage to fix them?

 Thanks by advance,
 --
 Youenn Piolet
 piole...@gmail.com


 --
 Manage your subscription for the Freeipa-users mailing list:
 https://www.redhat.com/mailman/listinfo/freeipa-users
 Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] 3rd party certificate for WebUI only

[Prasun Gera]

How smooth is the renewal process ? if the webui cert expires, does it
affect the core ipa functionality in any way ? Also, when ipa does it's own
auto-renewal, does it leave the webui alone if set up this way ?

On Wed, Jul 1, 2015 at 9:16 PM, Prashant Bapat prash...@apigee.com wrote:

 I had the exact same requirement. Since we're on AWS, I ended up putting a
 ELB in front of each of my IPA servers with a commercial cert for web UI.
 The communication between ELB and the IPA server is using the IPA CA cert.

 On 2 July 2015 at 07:03, Rob Crittenden rcrit...@redhat.com wrote:

 Stephen Ingram wrote:

 I setup IPA using the internal CA. I'd like to continue using this CA,
 however, I'd also like to allow authorized external browser users (who
 haven't imported our CA) to access the WebUI without receiving a
 warning. Is it possible to add a 3rd party certificate and CA such that
 it is only used for the WebUI using the instructions at
 http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP?

 Steve



 In a word: yes.

 I'd recommend making a backup of /etc/httpd/alias and
 /etc/httpd/conf.d/nss.conf  before doing this to make rolling back, if
 necessary, easier.

 rob

 --
 Manage your subscription for the Freeipa-users mailing list:
 https://www.redhat.com/mailman/listinfo/freeipa-users
 Go to http://freeipa.org for more info on the project



 --
 Manage your subscription for the Freeipa-users mailing list:
 https://www.redhat.com/mailman/listinfo/freeipa-users
 Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] hesitate to deploy freeipa

[Prasun Gera]

I've found that if you are setting up a new environment from scratch which
is mostly going to involve RHEL/Fedora systems, and that you have full
control over your network including DNS, DHCP etc., it should mostly be
smooth sailing. However, if you already have a network of old and new
machines running different versions and flavours of unix, there is
significantly more work involved. That is, there is significant complexity
on client side code as well which should not be discounted. Do a survey of
the state of client side support on different distributions. From my
experience, Ubuntu 12.04 is iffy. There's also an open ticket pushed to
'future' on FreeNAS, which is BSD based. IMO this is one of the major
hurdles for wider adoption.

On Fri, Jun 26, 2015 at 12:47 AM, Petr Spacek pspa...@redhat.com wrote:

 On 26.6.2015 09:21, Christopher Lamb wrote:
  A very important factor - at least to me is this community: It is vibrant
  and active, you get advice, they listen and change things. For example
 I
  can think of at least 3 changes made to the documentation in the last few
  months due to mistakes I had made!

 BTW if you feel that something is incorrect (not only) in the docs please
 file
 a bug. If you want to contribute even more then feel free to send patch!

 Git repository with documentation source code is available to you.

 See http://www.freeipa.org/page/Contribute/Documentation for further
 details
 or ask this list.

 Have a nice day!

 --
 Petr^2 Spacek

 --
 Manage your subscription for the Freeipa-users mailing list:
 https://www.redhat.com/mailman/listinfo/freeipa-users
 Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] hesitate to deploy freeipa

[Prasun Gera]

 More importantly, ipa-client-install is just a thin configuration tool. If
 ipa-client-install is not available on your platform you can configure
 everything manually and it will work (as long as the client is
 standard-compliant).

 I.e. the client side is *in the worst case* (without ipa-client-install)
 equally hard to setup as for any home-made solution.




Yes, on Ubuntu 12.04, the issue is probably more related to the script than
the underlying packages, which I upgraded from their respective ppas. The
most complete documentation for getting ipa running, ironically, comes from
this bug report
https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1280215 which is
marked as won't fix. (This affects 12.04 btw which is lts).

On FreeNAS, it has to do with Hiemdal v/s MIT kerberos.
https://bugs.pcbsd.org/issues/2147
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sudo (sssd) hangs due to ipa install/uninstall scripts

[Prasun Gera]

Thanks. It's good to know that it is fixed upstream. For discussion though,
are any enhancements planned for dealing with installation/removal of ipa ?

On Wed, Jun 24, 2015 at 12:49 AM, Jakub Hrozek jhro...@redhat.com wrote:

 On Tue, Jun 23, 2015 at 10:46:14PM -0700, Prasun Gera wrote:
  After spending a better part of the day, the culprit was this line in
  nsswitch.conf:
 
  sudoers: files sss sss

 Known ipa-client-install bug, fixed.

 
  It turns out that the extra sss left behind is sufficient to make any
 sudo
  command hang. Easy to reproduce too.

 Known sudo bug, fixed in upstream and making its way into downstreams:
 https://bugzilla.redhat.com/show_bug.cgi?id=1133657
 https://bugzilla.redhat.com/show_bug.cgi?id=1147498

 --
 Manage your subscription for the Freeipa-users mailing list:
 https://www.redhat.com/mailman/listinfo/freeipa-users
 Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] sudo (sssd) hangs due to ipa install/uninstall scripts

[Prasun Gera]

Version: idm 4.x on rhel 7.1

Yet again, I've discovered a problem with residual state left behind by ipa
client install and uninstall scripts. I was having some trouble with
autofs+sssd leading to users not being mapped correctly (got nobody users
for everything). So I tried theipa-client-automount --uninstall, followed
by ipa-client-install --uninstall, and then did a fresh install of the
client. The original autofs issue aside, I started getting hangs in sudo.
After spending a better part of the day, the culprit was this line in
nsswitch.conf:

sudoers: files sss sss

It turns out that the extra sss left behind is sufficient to make any sudo
command hang. Easy to reproduce too.

Regarding the original autofs problem, I don't have a conclusive
explanation yet, but explicitly adding nfsvers=3 seems to map users
correctly.

It's always scary to use these install and uninstall scripts. They always
tend to leave bits and pieces behind. Isn't there a cleaner way to achieve
this ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Fw: ssh problem with migrated FreeIPA client on EL7.1 --Solved

[Prasun Gera]

I had faced a similar issue a month ago, for which I had created a ticket.
https://fedorahosted.org/freeipa/ticket/4956

On Fri, Jun 5, 2015 at 7:30 AM, Alexander Bokovoy aboko...@redhat.com
wrote:

 On Fri, 05 Jun 2015, Christopher Lamb wrote:

 Hi Martin

 Thanks for updating the documenation!

 The suggested solution works not only my test servers, but also in the
 real world. This morning I migrated the last production server (ipa host)
 to the new FreeIPA KDC.

 Just out of idle curiosity,  why is the rm -f /var/lib/sss/db/* step
 required on our EL 7.1 + ipa-client 4.1 boxes, but not on our older EL 6.5
 + ipa-client 3.3.3 machines?

 Is the problem down to sssd? (on the EL 6.5 machines we are running sssd
 1.9.2, while on EL 7.1 we have sssd 1.12.2

 I think there are more object types supported by newer SSSD versions
 which aren't invalidated like users or groups.



 Cheers

 Chris



 From:   Martin Kosek mko...@redhat.com
 To: Christopher Lamb/Switzerland/IBM@IBMCH, Rob Crittenden
rcrit...@redhat.com, freeipa-users@redhat.com
 Cc: Jakub Hrozek jhro...@redhat.com
 Date:   05.06.2015 08:06
 Subject:Re: [Freeipa-users] Fw: ssh problem with migrated FreeIPA
client on EL7.1 --Solved



 On 06/04/2015 07:34 PM, Christopher Lamb wrote:

 Hi All

 I can now report back success (at least on my throwaway EL7.1 test VM).

 To switch an EL 7.1 + ipa-client 4.1 host from an old FreeIPA 3.3.3 KDC

 to

 a new FreeIPA 4.1 KDC 3 steps are required:

 1) ipa-client-install --uninstall

 2) rm -f /var/lib/sss/db/*

 3) ipa-client-install --server ldap.my.example.com --domain

 my.example.com

 -N

 Having done this, my free-ipa user successfully authenticates (e.g. ssh
 remote login with free-ipa user / password


 To switch EL 6.5 + ipa-client 3.3.3 hosts step 2) was not required.

 Kudos and thanks go to Rob C for suggesting step 2. (Note that the
 directory to be purged is /var/lib/sss/db/, not /var/lib/sssd/db/ as
 suggested earlier in this thread.


 Cool! Thanks for reaching back. I added this advice to the FreeIPA
 Troubleshooting guide too:

 http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_on_client


 Cheers

 Chris




 From:Martin Kosek mko...@redhat.com
 To:  Christopher Lamb/Switzerland/IBM@IBMCH,
  freeipa-users@redhat.com
 Cc:  Jakub Hrozek jhro...@redhat.com, Rob Crittenden
  rcrit...@redhat.com
 Date:03.06.2015 10:39
 Subject: Re: [Freeipa-users] Fw: ssh problem with
 migrated

 FreeIPA

  client on EL7.1 --Not Solved



 On 06/03/2015 10:30 AM, Christopher Lamb wrote:

 Hi all

 This is a quick(ish) note to bring everybody up to speed on this issue.
 Yesterday we had some private mail exchange on this issue as I did not

 wish

 to broadcast the krb5 and ipa install logs to the user list.

 The basic situation is that we are in the process of migrating from an
 FreeIPA 3.3.3 Server (KDC) to a new FreeIPA 4.1 Server (KDC). As

 discussed

 in a thread some weeks ago we did not do this by replicating (as perhaps

 we

 should have done). Instead we migrated the users across.

 We have 30+ servers that are IPA clients (Hosts in ipa-speak) joined

 to

 the old KDC. We are now in the process of migrating these hosts to the

 new

 4.1 KDC.

 Most of the hosts run EL 6.5 + ipa-client 3.3.3.  For all of these

 joining

 to the new KDC was trouble free, taking a few minutes each. After

 joining

 the new KDC FreeIPA users authenticated properly.

 We also had a small number of new EL 7.1 + ipa-client 4.1 hosts that

 were

 joined direct to the new 4.1 KDC, never having been joined of the 3.3.3
 KDC. These were also trouble free.

 The problem occurs with a handful of existing EL 7.1 +ipa-client 4.1

 hosts

 that were originally joined to the 3.3.3 KDC, and must be moved to join

 the

 4.1 KDC.  These machines no longer authenticate valid FreeIPA users. I

 have

 been able to reproduce this behaviour with a freshly setup VM joined

 first

 to the 3.3.3 KDC, then moved to the 4.1 KDC.

 While the errors show in the krb5 child logs indicate that the password

 is

 incorrect, the same user / password is happily accepted by all the other
 hosts.

 It seems that in the process of moving / migrating the EL 7.1 /

 ipa-client

 4.1 from the old KDC to the new KDC, something is left behind that

 causes

 problems. We have seen indications in the install logs that the kinit

 steps

 called during ipa-client install are getting responses from the wrong

 (old)

 KDC, and not from the new KDC.

 Frustratingly. over the weekend i managed to get one of the problem EL

 7.1

 boxes to work. However I can't work out exactly what I was that I did

 that

 did the trick. However it seems that some kind of major de-install /
 cleanup + reinstall of the ipa-client may be needed.

 Rob has suggested that as part of such a cleanup I should do rm
 -f 

Re: [Freeipa-users] Synology DSM5 and freeIPA

[Prasun Gera]

Thanks. Yes, the feature would be pretty useful. Do you have any thoughts
on the documentation blurb mentioned a couple of mails ago ( Use a remote
user  ...) ? The local root on the IPA server can be mapped to a
particular user on the NFS server. That bit sounds straightforward. The
other parts are less clear.



On Tue, Apr 14, 2015 at 3:03 AM, Martin Kosek mko...@redhat.com wrote:

 I am personally not aware of such deployment. The linux-nfs.org NFS
 HOWTOs we
 link from
 http://www.freeipa.org/page/HowTos#Authentication
 also uses no_root_squash.

 To do this properly, I assume you would need have some notification
 mechanism
 deployed on FreeIPA server, that would trigger the home directory creation
 on
 the server.

 (We have a ticket for it: https://fedorahosted.org/freeipa/ticket/1593)

 On 04/13/2015 08:58 PM, Prasun Gera wrote:
  Just a follow up. I thought that making NFS a service in IPA takes care
 of
  this, but it looks like the issues are unrelated. Home directories are
  created automatically if the user logs in to the NFS server, but I
 haven't
  found any solution to trigger this from a client without using
  no_root_squah for the mount on the IPA server. If someone has achieved
 this
  functionality, can you share your experience ?
 
  On Fri, Apr 10, 2015 at 1:05 PM, Prasun Gera prasun.g...@gmail.com
 wrote:
 
  Here's the link:
 
 
 
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/users.html#home-directories
 
  On Fri, Apr 10, 2015 at 12:42 PM, Dmitri Pal d...@redhat.com wrote:
 
   On 04/09/2015 07:44 PM, Prasun Gera wrote:
 
  I have a somewhat related question.  Without kerberizing NFS, which
 I'll
  do eventually since that needs all the clients to be migrated first,
 how
  does one create home directories automatically ? The IPA server and NFS
  server are different systems. I was able to verify that automatic home
  creation works if the NFS share is exported to the IPA server with
  no_root_squash. What's the proper way of doing this ?
 
 
  The documentation says:
 
 
  Which documentation you are referring to?
  Can you please post the link?
 
 
 
  Use a remote user who has limited permissions to create home
 directories
  and mount the share on the IdM server as that user. Since the IdM
 server
  runs as an httpd process, it is possible to use sudo or a similar
 program
  to grant limited access to the IdM server to create home directories
 on the
  NFS server.
 
 
 
  What would be the list of steps that would achieve this ? What are the
  limited permissions that the NFS user would need ? Read + Write, but no
  Delete to the /home directory ? Sounds like something that would need
 ACLs.
  And where does sudo on the IPA server fit into this ?
 
 
 
  On Thu, Mar 19, 2015 at 4:51 PM, Roberto Cornacchia 
  roberto.cornacc...@gmail.com wrote:
 
  Thanks, Jakub.
 
 
  On 19 March 2015 at 21:23, Jakub Hrozek jhro...@redhat.com wrote:
 
 
  On 19 Mar 2015, at 21:18, Roberto Cornacchia 
  roberto.cornacc...@gmail.com wrote:
 
  It's possible that I'm simply not getting the point, or that I don't
  understand the documentation correctly, but this is what I don't
 find clear:
 
  I had seen the instructions you pointed me at. These are not
  specifically about home directories.
 
  However, this section is:
 
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs
 
  It first suggests that automatic creation of home directories over
  NFS shares is possible: just automount /home and then use
  pam_oddjob_mkhomedir or pam_mkhomedir to create homedirs at first
 login.
 
  But then it also suggests that mounting the whole /home tree could
 be
  an issue, and says: Use automount to mount only the user's home
 directory
  and only when the user logs in, rather than loading the entire /home
 tree.
 
  That means that automatic homedir creation is out of the game,
  doesn't it?
 
  That's what I find confusing. What's the recommended way?
 
 
  It really depends on your environment. For your size, it's perfectly
  fine to NFS mount the whole /home tree and be done with it. Don't
 optimize
  prematurely :-)
 
 
 
  On 19 March 2015 at 20:49, Dmitri Pal d...@redhat.com wrote:
  On 03/19/2015 02:46 PM, Roberto Cornacchia wrote:
  Hi Dmitri,
 
  I do realise my question is borderline and I accept that it is
  considered off-topic.
 
  I did post it here because I believe it's not *only* about NFS, but
  also about its interaction with freeIPA. The issue of NFS home and in
  particular about their creation is touched in all the links I posted
 (all
  about freeIPA) and never really answered.
 
 
  This is what documented and recommended:
 
 
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs

Re: [Freeipa-users] Synology DSM5 and freeIPA

[Prasun Gera]

Just a follow up. I thought that making NFS a service in IPA takes care of
this, but it looks like the issues are unrelated. Home directories are
created automatically if the user logs in to the NFS server, but I haven't
found any solution to trigger this from a client without using
no_root_squah for the mount on the IPA server. If someone has achieved this
functionality, can you share your experience ?

On Fri, Apr 10, 2015 at 1:05 PM, Prasun Gera prasun.g...@gmail.com wrote:

 Here's the link:


 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/users.html#home-directories

 On Fri, Apr 10, 2015 at 12:42 PM, Dmitri Pal d...@redhat.com wrote:

  On 04/09/2015 07:44 PM, Prasun Gera wrote:

 I have a somewhat related question.  Without kerberizing NFS, which I'll
 do eventually since that needs all the clients to be migrated first, how
 does one create home directories automatically ? The IPA server and NFS
 server are different systems. I was able to verify that automatic home
 creation works if the NFS share is exported to the IPA server with
 no_root_squash. What's the proper way of doing this ?


 The documentation says:


 Which documentation you are referring to?
 Can you please post the link?



 Use a remote user who has limited permissions to create home directories
 and mount the share on the IdM server as that user. Since the IdM server
 runs as an httpd process, it is possible to use sudo or a similar program
 to grant limited access to the IdM server to create home directories on the
 NFS server.



 What would be the list of steps that would achieve this ? What are the
 limited permissions that the NFS user would need ? Read + Write, but no
 Delete to the /home directory ? Sounds like something that would need ACLs.
 And where does sudo on the IPA server fit into this ?



 On Thu, Mar 19, 2015 at 4:51 PM, Roberto Cornacchia 
 roberto.cornacc...@gmail.com wrote:

 Thanks, Jakub.


 On 19 March 2015 at 21:23, Jakub Hrozek jhro...@redhat.com wrote:


  On 19 Mar 2015, at 21:18, Roberto Cornacchia 
 roberto.cornacc...@gmail.com wrote:
 
  It's possible that I'm simply not getting the point, or that I don't
 understand the documentation correctly, but this is what I don't find 
 clear:
 
  I had seen the instructions you pointed me at. These are not
 specifically about home directories.
 
  However, this section is:
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs
 
  It first suggests that automatic creation of home directories over
 NFS shares is possible: just automount /home and then use
 pam_oddjob_mkhomedir or pam_mkhomedir to create homedirs at first login.
 
  But then it also suggests that mounting the whole /home tree could be
 an issue, and says: Use automount to mount only the user's home directory
 and only when the user logs in, rather than loading the entire /home tree.
 
  That means that automatic homedir creation is out of the game,
 doesn't it?
 
  That's what I find confusing. What's the recommended way?
 

 It really depends on your environment. For your size, it's perfectly
 fine to NFS mount the whole /home tree and be done with it. Don't optimize
 prematurely :-)

 
 
  On 19 March 2015 at 20:49, Dmitri Pal d...@redhat.com wrote:
  On 03/19/2015 02:46 PM, Roberto Cornacchia wrote:
  Hi Dmitri,
 
  I do realise my question is borderline and I accept that it is
 considered off-topic.
 
  I did post it here because I believe it's not *only* about NFS, but
 also about its interaction with freeIPA. The issue of NFS home and in
 particular about their creation is touched in all the links I posted (all
 about freeIPA) and never really answered.
 
 
  This is what documented and recommended:
 
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs
 
  RHEL6 has a similar chapter in its doc set though books have changed
 significantly between 6 and 7.
 
  I do not see any chicken and egg problem there.
  The instructions show how to create home dirs on the first login.
 
  It mounts the volume and then creates dirs on it as users log in if
 they are not already there.
 
  It is unclear what problem you see with doing it the way it is
 recommended.
 
 
 
  Best,
  Roberto
 
  On 19 March 2015 at 19:36, Dmitri Pal d...@redhat.com wrote:
  On 03/19/2015 05:29 AM, Roberto Cornacchia wrote:
  On 6 March 2015 at 11:15, Martin Kosek mko...@redhat.com wrote:
  On 03/06/2015 10:56 AM, Roberto Cornacchia wrote:
  Hi there,
 
  I'm planning to deploy freeIPA on our lan.
  It's small-ish and completely based on FC21, so I expect everything
 to work
  like a charm.
 
  Except one detail. We have Synology NAS station, which uses DSM 5.0.
  The ideal plan is to use it as host for shared NFS home dirs

Re: [Freeipa-users] Understanding the migration mode

[Prasun Gera]

I tried enabling crypt for experimentation, and things seem to work well
for both NIS and SSSD clients. I noticed that the crypt format that the NIS
plugin in IPA provides is the traditional crypt format with a 2 character
salt and 13 character hash. NIS clients can understand newer crypt
encodings which allow MD5, SHA256 and SHA512 (
https://docs.python.org/3/library/crypt.html) . Is it possible to force one
of those as the storage scheme in the directory server ?

On Tue, Mar 31, 2015 at 12:04 PM, Prasun Gera prasun.g...@gmail.com wrote:

 I've figured it out. You are right. SSSD triggers key generation. For
 migrated clients though, since ypbind still runs and the NIS-plugin serves
 maps, they authenticate first using NIS before SSSD. If ypbind is stopped,
 it is forced to use SSSD, and then it triggers the migration. Thanks for
 persisting with this. It's pretty clear how it works now.

 On Tue, Mar 31, 2015 at 11:32 AM, Prasun Gera prasun.g...@gmail.com
 wrote:



 ? SSSD does not seem to be involved as user is found in the /etc/passwd
 and this SSSD should not do anything.

 It's not  a local user. There's no entry in /etc/passwd. Here's the
 relevant sssd log


 sssd_ssh

 (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [sss_parse_name_for_domains]
 (0x0200): name 'testuser2' matched without domain, user is testuser2
 (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [client_recv] (0x0200): Client
 disconnected!
 (Tue Mar 31 03:53:17 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
 Received client version [0].

 sssd_pam

 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
 ipadomain
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): user:
 testuser2
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
 service: sshd
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
 not set
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
 host_ip
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
 type: 0
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
 newauthtok type: 0
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
 cli_pid: 23983
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
 name: testuser2
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100):
 pam_dp_send_req returned 0
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100):
 received: [0][ipadomain]
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply
 called with result [0].
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 27
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [client_recv] (0x0200): Client
 disconnected!



-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Understanding the migration mode

[Prasun Gera]

I had a look at ldap/servers/plugins/pwdstorage/crypt_pwd.c, and it looks
like it is hardcoded in crypt_pw_enc, which uses the default DES crypt
method. This only affects the encoding. The verification of passwords works
with any of MD5 or SHA-* schemes since the underlying crypt function in
recent glibcs supports them. Would it make sense to add the other options
to the encoding function ?

On Thu, Apr 2, 2015 at 3:27 AM, Prasun Gera prasun.g...@gmail.com wrote:

 I tried enabling crypt for experimentation, and things seem to work well
 for both NIS and SSSD clients. I noticed that the crypt format that the NIS
 plugin in IPA provides is the traditional crypt format with a 2 character
 salt and 13 character hash. NIS clients can understand newer crypt
 encodings which allow MD5, SHA256 and SHA512 (
 https://docs.python.org/3/library/crypt.html) . Is it possible to force
 one of those as the storage scheme in the directory server ?

 On Tue, Mar 31, 2015 at 12:04 PM, Prasun Gera prasun.g...@gmail.com
 wrote:

 I've figured it out. You are right. SSSD triggers key generation. For
 migrated clients though, since ypbind still runs and the NIS-plugin serves
 maps, they authenticate first using NIS before SSSD. If ypbind is stopped,
 it is forced to use SSSD, and then it triggers the migration. Thanks for
 persisting with this. It's pretty clear how it works now.

 On Tue, Mar 31, 2015 at 11:32 AM, Prasun Gera prasun.g...@gmail.com
 wrote:



 ? SSSD does not seem to be involved as user is found in the /etc/passwd
 and this SSSD should not do anything.

 It's not  a local user. There's no entry in /etc/passwd. Here's the
 relevant sssd log


 sssd_ssh

 (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [sss_parse_name_for_domains]
 (0x0200): name 'testuser2' matched without domain, user is testuser2
 (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [client_recv] (0x0200): Client
 disconnected!
 (Tue Mar 31 03:53:17 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
 Received client version [0].

 sssd_pam

 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
 domain: ipadomain
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): user:
 testuser2
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
 service: sshd
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): tty:
 ssh
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
 not set
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
 host_ip
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
 authtok type: 0
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
 newauthtok type: 0
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
 cli_pid: 23983
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
 name: testuser2
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100):
 pam_dp_send_req returned 0
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100):
 received: [0][ipadomain]
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply
 called with result [0].
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 27
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [client_recv] (0x0200): Client
 disconnected!




-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Understanding the migration mode

[Prasun Gera]

 The idea is that you tel lall the users to either login via migration page
 or via SSSD.
 If your server is in a migration mode the migration page should be
 available and SSSD should detect that server is in migration mode.
 In this case any authentication via SSSD will end up creating proper
 hashes for Kerberos. I suspect this is when the conversion of the LDAP
 hashes happens too.
 You suggested that this is not the case but I am not sure that the test
 was 100 correct.

 Please try:
 - check that migration mode is on
 - check that user does not have kerberos password only LDAP hash from NIS
 migration
 - ssh into a box that runs SSSD with such user, authenticate
 As a result you should see Kerberos hash created for this user and I
 suspect the LDAP hash is converted at the same time.


I verified all the steps, and I can confirm that SSSD does not migrate
users automatically.
I see the following in /var/log/secure, which confirms that sssd is indeed
authenticating the user

Mar 31 03:50:47 ipaserver sshd[23531]: Accepted password for testuser2 from
ip port 43622 ssh2
Mar 31 03:50:47 ipaserver sshd[23531]: pam_unix(sshd:session): session
opened for user testuser2 by (uid=0)

ipa user-show testuser2 still shows Kerberos keys available: False

sssd's logs also show successful authentication.

I think this sounds reasonable (and possibly intentional?) since the
alternative would make staged migration impossible. As soon as one client
is migrated, all other clients would lose the ability to authenticate with
NIS. The way it is behaving right now is actually preferable. i.e. No
automatic migration until done explicitly by user/admin.

Coming back to the original issue, I deleted those accidentally migrated
users and added them again, and I haven't seen any anomalous behaviour
since. i.e Their cypt hashes are visible to NIS clients. I can only guess
that whatever triggered it in the first place was a one-off event. Could
yum update be responsible ? All the free ipa packages were updated last
week to the latest point release. In any case, I think it is behaving well
for now, and hope it stays that way.

Minor question: Our NIS maps had separate shadow maps originally, which
provided some mild security since they can't be accessed by unprivileged
users/ports. Is it possible to do that with the NIS plugin in IPA ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Understanding the migration mode

[Prasun Gera]

I've figured it out. You are right. SSSD triggers key generation. For
migrated clients though, since ypbind still runs and the NIS-plugin serves
maps, they authenticate first using NIS before SSSD. If ypbind is stopped,
it is forced to use SSSD, and then it triggers the migration. Thanks for
persisting with this. It's pretty clear how it works now.

On Tue, Mar 31, 2015 at 11:32 AM, Prasun Gera prasun.g...@gmail.com wrote:



 ? SSSD does not seem to be involved as user is found in the /etc/passwd
 and this SSSD should not do anything.

 It's not  a local user. There's no entry in /etc/passwd. Here's the
 relevant sssd log


 sssd_ssh

 (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [sss_parse_name_for_domains]
 (0x0200): name 'testuser2' matched without domain, user is testuser2
 (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [client_recv] (0x0200): Client
 disconnected!
 (Tue Mar 31 03:53:17 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200):
 Received client version [0].

 sssd_pam

 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
 ipadomain
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): user:
 testuser2
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): service:
 sshd
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
 not set
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
 host_ip
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
 type: 0
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100):
 newauthtok type: 0
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
 23983
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
 name: testuser2
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100):
 pam_dp_send_req returned 0
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100):
 received: [0][ipadomain]
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply
 called with result [0].
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 27
 (Tue Mar 31 03:53:54 2015) [sssd[pam]] [client_recv] (0x0200): Client
 disconnected!

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Understanding the migration mode

[Prasun Gera]

 The passwords will only show if they are in {crypt} format. If the
 password is changed in IPA it will use the default 389-ds password
 scheme which is a salted SHA.


Yes, that's right. If the password is changed in IPA afterwards, it will
stop working for NIS clients. This is the expected behaviour and that's
fine.



 It may be, though I didn't think this was
 the case, that the password is being re-hashed during kerberos key
 generation.


The kerberos keys for these users shouldn't be generated at all right ? So
far I have been using the special webui page (/ipa/migration) to elevate
old users to regular IPA users. The migration webui page needs the
plaintext password in order to generate the kerberos keys. Until the
migration step is complete, there are no kerberos keys. And that seems all
right. i.e. Elevation to IPA users should happen only intentionally.



 How long will you need to keep these legacy systems? This sharing of the
 password hashes is one of the (many) reasons people are migrating from NIS.


These clients are actually not even that old. Most of them are on Ubuntu
12.04 or thereabouts. IPA client support on Ubuntu systems seems to be a
bit buggy. I did manage to get it to work with ppas for ipa and sssd after
some minor changes. This has improved in 14.04 from what I read, and it
might be a better idea to bring the clients up to that before migrating.



 A fix may be to change the 389-ds password hashing scheme to crypt but
 that may just let these NIS systems linger forever. So it's the typical
 balance of usability vs security.


I don't think the problem is the hashing scheme itself.  The old users'
passwords were encrypted using MD5 and that's how I had imported them.
Changing the scheme to something else after importing won't affect these
passwords anyway right ? Or do you mean that if I change 389-ds's scheme to
MD5 now, even if these users are elevated to IPA users, their hashes will
continue to be visible from NIS clients. I thought the encryption scheme
itself, and whether on not NIS clients see the encrypted password were two
separate issues.




 rob

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Understanding the migration mode

[Prasun Gera]

 Keys can be generated in migration in two ways: by the migration web UI
 or by sssd. I'm guessing you were unaware of this second method and that
 is how the keys are being created.


That's what I suspected too. But it doesn't look like SSSD is generating
keys. At least not right away. I SSHed to one of the clients with
ipa-client installed as well as to the ipa-server, and that didn't change
anything right away. That's what I was trying to figure out. i.e Which
event triggers key generation ?



 I'd suggest using nss_ldap over NIS. You can also manually configure
 Kerberos and have basic functionality as long as nscld doesn't drive you
 crazy.


Thanks. I'll look into it.



 It's not the encryption type, it is how it is encoded in 389-ds. When
 you migrated the passwords they were stored as {crypt}hash. When the
 password is changed in 389-ds it becomes {SSHA}hash. The NIS
 configuration for slapi-nis only provides those passwords prefixed with
 {crypt} (because NIS can only grok that format).


 rob


Yeah that sounds like a possible fix, although a less than ideal one. Is it
possible to change it back to {SSHA} after all the clients have been
migrated suitably ? How would one force all the existing users' passwords
to be converted to {SSHA} once slapi-nis is no longer needed ?
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Understanding the migration mode

[Prasun Gera]

Hello,
I followed
https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords in
order to migrate our NIS installation, and for the most part it worked. The
server responds to ypcat from the NIS clients, and users can log in.
However, I'm seeing a couple of weird issues. Normally, ypcat returns
username:cryptpass:uid:gid:gecos:homedir:shell  for users and
authentication works fine. For new users that were added directly to IPA,
instead of the cryptpass, I see an asterisk(*), which is also
understandable. However, for a couple of migrated users, I'm seeing that
their cyrptpasses have also been replaced with *s (in ypcat's output) over
the course of time. This creates problems for authentication on clients
that haven't been migrated, and they can't log in with their passwords.
These users didn't explicitly call kinit or go to the webui for migration.
Is it normal for the crypt passes to be replaced by *? I migrated a couple
of clients, and these users would have sshed to the migrated clients or
possibly to the server. That didn't seem to affect ypcat's behaviour
directly, and yet that is the only thing I can think of that has any
connection to this.

Regards,
Prasun
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Understanding the migration mode

[Prasun Gera]

Yes, that is right. I added the users with ipa user-add [username]
--setattr userpassword={crypt}yourencryptedpass

Actually, the authentication does work for the users added this way. i.e.
Without making any changes to NIS clients. I just repurposed the NIS server
to be the IPA server, turned off the ypserv  yppasswd service, and enabled
the slapi-nis plugin. So far so good, and the NIS clients continue to
function normally. i.e. The NIS plugin on the IPA server DOES distribute
the cryptpasses. I also didn't expect the old NIS clients to authenticate
any new users added to IPA directly, and that is all right. I just want the
clients to function for the existing users until they are migrated. The
only thing that is slightly puzzling is that a couple of users have been
migrated unintentionally, so to speak.

A user can be explicitly migrated to IPA if (s)he generates the kerberos
keys, at which point the slapi-nis stops distributing the crypt pass for
that user. This is what I have observed so far, and it sounds reasonable.
(This can also be confirmed with ipa user-show, which in case of these old
users shows Kerberos keys available: False, which turns to True once
properly migrated. It can also be confirmed from the webui. The old
password won't work in the webui until migrated, and once migrated, NIS
cryptpasses will stop working).

However, what I'm seeing is that in a couple of cases, the users have been
migrated to IPA automatically. Their status shows Kerberos keys available:
True, and their cryptpasses have changed to * in ypcat passwd's output.





On Thu, Mar 26, 2015 at 5:59 PM, Dmitri Pal d...@redhat.com wrote:

  On 03/26/2015 02:29 PM, Prasun Gera wrote:

 Hello,
 I followed
 https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
 in order to migrate our NIS installation, and for the most part it worked.
 The server responds to ypcat from the NIS clients, and users can log in.
 However, I'm seeing a couple of weird issues. Normally, ypcat returns
 username:cryptpass:uid:gid:gecos:homedir:shell  for users and
 authentication works fine. For new users that were added directly to IPA,
 instead of the cryptpass, I see an asterisk(*), which is also
 understandable. However, for a couple of migrated users, I'm seeing that
 their cyrptpasses have also been replaced with *s (in ypcat's output) over
 the course of time. This creates problems for authentication on clients
 that haven't been migrated, and they can't log in with their passwords.
 These users didn't explicitly call kinit or go to the webui for migration.
 Is it normal for the crypt passes to be replaced by *? I migrated a couple
 of clients, and these users would have sshed to the migrated clients or
 possibly to the server. That didn't seem to affect ypcat's behaviour
 directly, and yet that is the only thing I can think of that has any
 connection to this.

  Regards,
 Prasun



 Based on what you describe I assume that you:
 - Migrated users to IPA
 - Enabled slapi-nis plugin
 - Use old clients with slapi-nis as a NIS server and expect to be able to
 authenticate with new and old users against IPA NIS map.

 Right?

 So the authentication does not work and this is by design since passwords
 in files are insecure and distributing them centrally as NIS did is
 security problem.
 The suggestion is to change the authentication method on old clients to
 LDAP or Kerberos first, whatever they support (they usually do even if they
 are quite old), and leave NIS for identity information only since some old
 clients do not support LDAP for that part and only support NIS.

 --
 Thank you,
 Dmitri Pal

 Sr. Engineering Manager IdM portfolio
 Red Hat, Inc.


 --
 Manage your subscription for the Freeipa-users mailing list:
 https://www.redhat.com/mailman/listinfo/freeipa-users
 Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Debian 7.0.8 and REHL IPA

[Prasun Gera]

I tried setting up the client on an ubuntu 12.04 system, and had some
initial hiccups. I used the ppa for ipa and sssd. This bug report lists
some pitfalls:
https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1280215. I don't
know why it is marked as won't fix, but it affects 12.04, which is LTS. I
had to manually add

mkdir -p /etc/pki/nssdb 
certutil -N --empty-password -d /etc/pki/nssdb


for the client to install. The client install script doesn't do this on
ubuntu. It is possible that some of the other reported issues have been
fixed. It's best to do this on system you have physical access to.
A botched install could lock you out of ssh.



On Tue, Mar 24, 2015 at 5:53 PM, Will Sheldon m...@willsheldon.com wrote:



 There is a ppa for ubuntu:
 https://code.launchpad.net/~freeipa/+archive/ubuntu/ppa

 and packages in the deb archives:
 https://packages.qa.debian.org/f/freeipa.html


 I’ve had mixed results using them, there seem to be frequent regressions
 so having a canary machine / cluster is essential.

 The install script also had some issues, but I believe it’s better now?
 last time I tried was about 12 months ago.


 Will.



 On March 24, 2015 at 2:29:09 PM, Steven Jones (steven.jo...@vuw.ac.nz)
 wrote:

 Hi,

 Anyone have experience with running the sssd client (I assume its
 available) on Debian 7.0.8 against a RH IPA setup?

 Is it painless long term or best avoided?

 regards

 Steven

 --
 Manage your subscription for the Freeipa-users mailing list:
 https://www.redhat.com/mailman/listinfo/freeipa-users
 Go to http://freeipa.org for more info on the project


 --
 Manage your subscription for the Freeipa-users mailing list:
 https://www.redhat.com/mailman/listinfo/freeipa-users
 Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project