Re: [Freeipa-users] Announcing FreeIPA 4.4.2

[Martin Kosek]

On 10/14/2016 03:29 PM, Coy Hile wrote:
> 
> 
> Will there be builds in a COPR for rhel/cents 7?

I would recommend waiting on RHEL-7.3, which should be released soon enough.
RHEL-7.3 contains an IdM/FreeIPA version that is very close to upstream version
4.4.2.

Martin

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

Re: [Freeipa-users] Announcing FreeIPA 4.4.2

[Martin Kosek]

On 10/13/2016 09:17 PM, Petr Vobornik wrote:
> The FreeIPA team would like to announce FreeIPA 4.4.2 release!
> 
> It can be downloaded from http://www.freeipa.org/page/Downloads. Builds
> for Fedora 24 will be available in the official COPR repository
> .
> 
> This announcement is also available on
> http://www.freeipa.org/page/Releases/4.4.2
> 
> Fedora 25 update:
> https://bodhi.fedoraproject.org/updates/freeipa-4.4.2-1.fc25

Please note that the FreeIPA Public demo was also upgraded to the version
4.4.2, if you want to try it out!

Demo location: https://ipa.demo1.freeipa.org/ipa/ui/

The selected new features that may be best exhibited in the FreeIPA Web UI:

* Improved Topology Management:
  - IPA Server -> Topology -> Graph
  - https://ipa.demo1.freeipa.org/ipa/ui/#/p/topology-graph

* Added Overview of IPA server roles:
  - IPA Server -> Topology -> Server Roles
  - https://ipa.demo1.freeipa.org/ipa/ui/#/e/server_role/search
  - You can click on a role

  - You can also see roles of a server:
  - 
https://ipa.demo1.freeipa.org/ipa/ui/#/e/server/details/ipa.demo1.freeipa.org

* Added DNS Location Mechanism:
  - IPA Server -> Topology -> IPA Locations
  - You can add a location
  - In the location details, you can add the servers to it (you can only test
UI as changing a location of IPA server requires DNS server restart)

* Added support for Sub-CAs
  - Open Authentication -> Certificate Authorities
  - Add new CA Authority, with subject like "CN=Certificate
Authority,O=VPN,O=DEMO1.FREEIPA.ORG"
  - Set ACL for authority in "CA ACLs" so that Admin can use this CA
  - Generate new certificate:
 - Open for example a test Service
 - Click Options -> New Certificate
 - Follow the steps (and use the new Sub-CA). I typed these options to get
the CSR:
   - cd /tmp/
   - mkdir test
   - cd test/
   - certutil -N -d .
   - certutil -R -d . -a -g 2048 -s
'CN=ipa.demo1.freeipa.org,O=VPN,O=DEMO1.FREEIPA.ORG' -8 'ipa.demo1.freeipa.org'
 - Paste the CSR blob to FreeIPA, it should pass
 - It will show that Issuer is "CN = Certificate Authority,O = VPN,O =
DEMO1.FREEIPA.ORG", i.e. our new Sub-CA

Enjoy!
Martin

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

Re: [Freeipa-users] Cleaning Up an Unholy Mess

[Martin Kosek]

On 08/25/2016 08:04 PM, Ian Harding wrote:
> 
> 
> On 08/25/2016 10:41 AM, Rob Crittenden wrote:
>> Ian Harding wrote:
>>>
>>>
>>> On 08/24/2016 06:33 PM, Rob Crittenden wrote:
 Ian Harding wrote:
> I tried to simply uninstall and reinstall freeipa-dal and this
> happened.
>
> It only had a replication agreement with freeipa-sea
>
> [root@freeipa-dal ianh]# ipa-server-install --uninstall
>
> This is a NON REVERSIBLE operation and will delete all data and
> configuration!
>
> Are you sure you want to continue with the uninstall procedure?
> [no]: yes
> Shutting down all IPA services
> Removing IPA client configuration
> Unconfiguring ntpd
> Configuring certmonger to stop tracking system certificates for KRA
> Configuring certmonger to stop tracking system certificates for CA
> Unconfiguring CA
> Unconfiguring named
> Unconfiguring ipa-dnskeysyncd
> Unconfiguring web server
> Unconfiguring krb5kdc
> Unconfiguring kadmin
> Unconfiguring directory server
> Unconfiguring ipa_memcached
> Unconfiguring ipa-otpd
> [root@freeipa-dal ianh]# ipa-server-install --uninstall
>
> This is a NON REVERSIBLE operation and will delete all data and
> configuration!
>
> Are you sure you want to continue with the uninstall procedure?
> [no]: yes
>
> WARNING: Failed to connect to Directory Server to find information
> about
> replication agreements. Uninstallation will continue despite the
> possible
> existing replication agreements.
> Shutting down all IPA services
> Removing IPA client configuration
> Configuring certmonger to stop tracking system certificates for KRA
> Configuring certmonger to stop tracking system certificates for CA
> [root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns
> --no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg
> Directory Manager (existing master) password:
>
> The host freeipa-dal.bpt.rocks already exists on the master server.
> You should remove it before proceeding:
>   % ipa host-del freeipa-dal.bpt.rocks
> [root@freeipa-dal ianh]#
>
> So I tried to delete it again with --force
>
> [root@freeipa-sea ianh]# ipa-replica-manage --force del
> freeipa-dal.bpt.rocks
> Directory Manager password:
>
> 'freeipa-sea.bpt.rocks' has no replication agreement for
> 'freeipa-dal.bpt.rocks'
> [root@freeipa-sea ianh]#
>
> Can't delete it from the master server either
>
> [root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks
> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or
> disabled
>
>
> Now what?  I'm running out of things that work.

 Not sure what version of IPA you have but try:

 # ipa-replica-manage --force --cleanup delete freeipa-dal.bpt.rocks

 If this had a CA on it then you'll want to ensure that any replication
 agreements it had have been removed as well.

 rob

>>>
>>> It turns out I'm not smart enough to untangle this mess.
>>>
>>> Is there any way to kind of start over?  I managed to delete and
>>> recreate a couple replicas but the problems (obsolete ruv as far as I
>>> can tell) carry on with the new replicas.  They won't even replicate
>>> back to the master they were created from.
>>
>> Once you have the right version of 389-ds then then cleanruv tasks work
>> a lot better. What version are you running now?
> 
> 1.3.4.0.  It's handcuffed to my CentOS 7 so I don't want to update it
> outside the CentOS ecosystem.  What's the downside of upgrading it from
> source or an RPM for a different flavor of RedHat derived Linux?
> 
> I'm a one-man band but I'd be interested in hearing a pitch from someone
> who is super smart on this stuff for a working consulting gig and maybe
> ongoing support.  Who would I talk to at RedHat about coming in from the
> cold for full on corporate support?

This sounds like you want to call
https://www.redhat.com/en/about/contact/sales#
:-)

-- 
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 password no more working

[Martin Kosek]

On 08/18/2016 04:16 PM, Deepak Dimri wrote:
> Hi All,
> 
> While trying to automate IPA client registration programatically, i seems 
> have 
> made my admin password out of sync between KDC and
> /etc/krb5.keytab.

This looks confusing, admin password and /etc/krb5.keytab do not look related.
The keytab is for host keytab.

> Now when i try login into ipa GUI via admin i am getting "The 
> password or username is incorrect" - though i am trying with the correct 
> password that i have been using. Is there anyway i can login to GUI in this 
> situation? Is there anyway i can get my admin password reseted or something? 
> i 
> can run my ansible playbooks w/out any issues on the linux host but cannot 
> login 
> to GUI any more...

Can you log in to GUI with other logins. If not, then check this page:
http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI

Martin

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

Re: [Freeipa-users] FreeIPA / CentOS 7.2 / Issues on Startup

[Martin Kosek]

On 08/18/2016 12:48 AM, Devin Acosta wrote:
> 
> My first primary FreeIPA Master server has gone belly up. When I try to start 
> the server it shows this message in the "error' log. However the other issue 
> i 
> have is when I try to start the server using "ipactl start" it times out 
> after 
> 300 seconds, how do I get past this issue?
> 
> [17/Aug/2016:22:44:57 +] SSL Initialization - Configured SSL version 
> range: 
> min: TLS1.0, max: TLS1.2
> [17/Aug/2016:22:44:57 +] - 389-Directory/1.3.4.0  
> B2016.215.1556 starting up
> [17/Aug/2016:22:44:57 +] - WARNING: changelog: entry cache size 2097152B 
> is 
> less than db size 28016640B; We recommend to increase the entry cache size 
> nsslapd-cachememsize.
> [17/Aug/2016:22:44:57 +] - Detected Disorderly Shutdown last time 
> Directory 
> Server was running, recovering database.
> 
> 
> Any help is greatly needed!!

My best guess is that your
/etc/dirsrv/slapd-YOUR-REALM/dse.ldif
got damaged when DS crashed/whatever and it now does not export the 636 port,
which is being checked by ipactl start.

You can try to start just the DS service with "service start dirsrv@YOUR-REALM"
and see if it opens port 636 with

netstat -putnl | grep 636
tcp6   0  0 :::636  :::*LISTEN
48550/ns-slapd

If it is not open, you can try to stop DS and use other dse.ldif from the
directory above, that is not corrupt. There should be some backups.

Martin

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

Re: [Freeipa-users] KDC returned error string: NOT_ALLOWED_TO_DELEGATE

[Martin Kosek]

On 08/16/2016 09:25 AM, Petr Spacek wrote:
> On 15.8.2016 20:18, Linov Suresh wrote:
>> We have IPA replica set up in RHEL 6.4 and is FreeIPA 3.0.0
>>
>>
>> We can only add the clients from IPA Server 01, not from IPA Server 02.
>> When I tried to add the client from IPA Server 02, getting the error,
>>
>>
>> ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error:
>> Unspecified GSS failure.  Minor code may provide more information (KDC
>> returned error string: NOT_ALLOWED_TO_DELEGATE)
>>
>> SASL/GSSAPI authentication started
>>
>> SASL username: vp...@example.net
>>
>> SASL SSF: 56
>>
>> SASL data security layer installed.
>>
>> ldap_modify: No such object (32)
>>
>> additional info: Range Check error
>>
>> modifying entry "fqdn=cpe-5061747522f9.example.net
>> ,cn=computers,cn=accounts,dc=example,dc=net"
>>
>>
>> Could you please help us to fix this?
> 
> We need to see exact steps you did before we can give you any meaningful 
> advice.
> 
> Please have a look at
> http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
> 
> It is a very nice document which describes general bug reporting procedure and
> best practices.
> 
> We will certainly have a look but we need first see the information :-)
> 

Also, using IPA on RHEL-6.4 is discouraged. This is a really old release and
there are known issues (in cert renewals for example). Using at least RHEL-6.8
or, even better, RHEL-7.2 is preferred and would help you avoid known issues
and deficiencies (and the newer FreeIPA versions are way cooler anyway).

-- 
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 LDAP Directory Extenion

[Martin Kosek]

Please check the FreeIPA training presentation. There are more details for
this. TLDR, you will need to create one Python plugin to get this into API/CLI
and one Web UI plugin if you also want to extend Web UI. The presentation above
has some examples.

On 08/09/2016 02:20 PM, Deepak Dimri wrote:
> Ok, got it, Martin
> 
> One more query on this.
> 
> I have extended the ObjectClass under inerorgperson and added the custom
> attributes successfully. i could add my newly custom ObjectClass under 
> "default
> user object class" tab of my FreeIPA configuration. But then the question how
> do i use these attributes? i dont event see them listed under user identity
> profile along with other out of the attributes like first name, address etc..
> 
> Best Regards,
> Deepak
> 
> 
>> Subject: Re: [Freeipa-users] FreeIPA LDAP Directory Extenion
>> To: deepak_di...@hotmail.com; mba...@redhat.com; freeipa-users@redhat.com
>> From: mko...@redhat.com
>> Date: Tue, 9 Aug 2016 11:10:09 +0200
>>
>> Hi Deepak,
>>
>> This console is not available for regular or shipped with FreeIPA (AFAIK), it
>> is only included in the Red Hat Directory Server product. With FreeIPA, you
>> will need to extend the schema with CLI tools (ldapmodify) as indicated in 
>> the
>> presentation that Martin Basti shared.
>>
>> Martin
>>
>> On 08/09/2016 11:06 AM, Deepak Dimri wrote:
>> > Thanks Martin, This helps!
>> >
>> > i also like this
>> > link
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html#extending-the-schema
>> >
>> > would you know how can i access "Directory Server Console" what file i 
>> > need to
>> > run to open it how its given in this document
>> >
>> > Regards,
>> > Deepak
>> >
>> >
>> > ---
>> > Subject: Re: [Freeipa-users] FreeIPA LDAP Directory Extenion
>> > To: deepak_di...@hotmail.com; freeipa-users@redhat.com
>> > From: mba...@redhat.com
>> > Date: Tue, 9 Aug 2016 10:15:47 +0200
>> >
>> >
>> >
>> >
>> > On 09.08.2016 10:08, Deepak Dimri wrote:
>> >
>> > Hi All,
>> >
>> > I want to extend my FreeIPA Directory Scheme - want to add a new
>> > ObjectClass and add few attributes to existing person ObjectClass. I see
>> > lot of places it is mentioned i can do it through 389-console command but i
>> > dont find it in my freeIPA server. I am getting ObjectClass not found
>> > error when trying to add using FreeIPA admin gui configuration tab. Is
>> > there any documentarians steps available how schema can be extended in
>> > freeIPA using GUI or outside? I am not finding any helpful material on this
>> > and hence thought of checking with you all!
>> >
>> > Thanks,
>> > Deepak
>> >
>> >
>> >
>> > Hello,
>> >
>> > please read [pages 6-7]
>> > https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf
>> >
>> > You should *not* extend IPA objectclasses, you have to create own, 
>> > otherwise we
>> > may and will break your schema during upgrade
>> >
>> > Martin
>> >
>> >
>>

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

Re: [Freeipa-users] FreeIPA LDAP Directory Extenion

[Martin Kosek]

Hi Deepak,

This console is not available for regular or shipped with FreeIPA (AFAIK), it
is only included in the Red Hat Directory Server product. With FreeIPA, you
will need to extend the schema with CLI tools (ldapmodify) as indicated in the
presentation that Martin Basti shared.

Martin

On 08/09/2016 11:06 AM, Deepak Dimri wrote:
> Thanks Martin, This helps!
> 
> i also like this
> link 
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html#extending-the-schema
> 
> would you know how can i access "Directory Server Console" what file i need to
> run to open it how its given in this document
> 
> Regards,
> Deepak
> 
> 
> ---
> Subject: Re: [Freeipa-users] FreeIPA LDAP Directory Extenion
> To: deepak_di...@hotmail.com; freeipa-users@redhat.com
> From: mba...@redhat.com
> Date: Tue, 9 Aug 2016 10:15:47 +0200
> 
> 
> 
> 
> On 09.08.2016 10:08, Deepak Dimri wrote:
> 
> Hi All,
> 
> I want to extend my FreeIPA Directory Scheme - want to add a new
> ObjectClass and add few attributes to existing person ObjectClass. I see
> lot of places it is mentioned i can do it through 389-console command but 
> i
> dont find it in my freeIPA server.  I am getting ObjectClass not found
> error when trying to add using FreeIPA admin gui configuration tab. Is
> there any documentarians steps available how schema can be extended in
> freeIPA using GUI or outside? I am not finding any helpful material on 
> this
> and hence thought of checking with you all!
> 
> Thanks,
> Deepak
> 
> 
> 
> Hello,
> 
> please read [pages 6-7]
> https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf
> 
> You should *not* extend IPA objectclasses, you have to create own, otherwise 
> we
> may and will break your schema during upgrade
> 
> Martin
> 
> 

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

Re: [Freeipa-users] IPA and FIPS 140-2

[Martin Kosek]

Ok, good! BTW, I opened the IPA and FIPS bug to the public, so that everyone
can track the progress:

https://bugzilla.redhat.com/show_bug.cgi?id=1125174

Martin

On 08/08/2016 04:24 PM, Michael Sean Conley wrote:
> Yep, did so right away.  and yes, this is for the future state of IPA.
> 
> 
> *Michael Sean Conley*
> Hardware/Infrastructure
> Intelligence, Information and Services
> *Raytheon Company*
> 972-643-9887 (office)
> 
> michael.sean.con...@raytheon.com
> 
> Inactive hide details for Martin Kosek ---08/05/2016 06:33:27 AM---Are you now
> asking about when upstream version is FIPS complMartin Kosek ---08/05/2016
> 06:33:27 AM---Are you now asking about when upstream version is FIPS compliant
> or some downstream distribution? If
> 
> From: Martin Kosek 
> To: Michael Sean Conley , Rob Crittenden
> 
> Cc: freeipa-users@redhat.com
> Date: 08/05/2016 06:33 AM
> Subject: Re: [Freeipa-users] IPA and FIPS 140-2
> 
> ---
> 
> 
> 
> Are you now asking about when upstream version is FIPS compliant or some
> downstream distribution? If you are asking about RHEL, as indicated by
> https://bugzilla.redhat.com/show_bug.cgi?id=1125174
> the bug is still in a NEW state. Given the state of RHEL-7.3 life cycle, it is
> too late to add it there.
> 
> However, as Rob mentioned, it would really great if you file a support case 
> (if
> we are talking about RHEL) and get it linked to that bug. Due to the interest,
> it is already high in the RHEL-7.4 considerations, but adding +1 won't hurt 
> and
> you may also receive updates on development status.
> 
> Martin
> 
> On 08/04/2016 06:40 PM, Michael Sean Conley wrote:
>> Is there any indication of a timeframe for it to become FIPS compliant?  If 
>> we
>> are talking weeks, rather than years...
>>
>> *Michael Sean Conley*
>>
>>
>> Inactive hide details for Rob Crittenden ---08/04/2016 11:37:23 AM---Michael
>> Sean Conley wrote: > Does ANYONE have any experienRob Crittenden 
>> ---08/04/2016
>> 11:37:23 AM---Michael Sean Conley wrote: > Does ANYONE have any experience
>> getting IPA to work with FIPS?
>>
>> From: Rob Crittenden 
>> To: Michael Sean Conley ,
>> freeipa-users@redhat.com
>> Date: 08/04/2016 11:37 AM
>> Subject: Re: [Freeipa-users] IPA and FIPS 140-2
>>
>> ---
>>
>>
>>
>> Michael Sean Conley wrote:
>>> Does ANYONE have any experience getting IPA to work with FIPS?
>>>
>>> We're trying desperately to get this going, as we have some requirements
>>> that the Identity Management Tool we choose must be FIPS 140-2 compliant.
>>
>> No, it doesn't work in FIPS mode yet. If you open a support case with
>> Red Hat your case can be added to
>> https://bugzilla.redhat.com/show_bug.cgi?id=1125174
>>
>> While most, if not all, of the individual components can run in FIPS
>> mode there are a lot of moving parts to coordinate to ensure they comply
>> with the FIPS Security Policy and to handle some corner cases in the
>> management framework.
>>
>> 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] IPA and FIPS 140-2

[Martin Kosek]

Are you now asking about when upstream version is FIPS compliant or some
downstream distribution? If you are asking about RHEL, as indicated by
https://bugzilla.redhat.com/show_bug.cgi?id=1125174
the bug is still in a NEW state. Given the state of RHEL-7.3 life cycle, it is
too late to add it there.

However, as Rob mentioned, it would really great if you file a support case (if
we are talking about RHEL) and get it linked to that bug. Due to the interest,
it is already high in the RHEL-7.4 considerations, but adding +1 won't hurt and
you may also receive updates on development status.

Martin

On 08/04/2016 06:40 PM, Michael Sean Conley wrote:
> Is there any indication of a timeframe for it to become FIPS compliant?  If we
> are talking weeks, rather than years...
> 
> *Michael Sean Conley*
> 
> 
> Inactive hide details for Rob Crittenden ---08/04/2016 11:37:23 AM---Michael
> Sean Conley wrote: > Does ANYONE have any experienRob Crittenden ---08/04/2016
> 11:37:23 AM---Michael Sean Conley wrote: > Does ANYONE have any experience
> getting IPA to work with FIPS?
> 
> From: Rob Crittenden 
> To: Michael Sean Conley ,
> freeipa-users@redhat.com
> Date: 08/04/2016 11:37 AM
> Subject: Re: [Freeipa-users] IPA and FIPS 140-2
> 
> ---
> 
> 
> 
> Michael Sean Conley wrote:
>> Does ANYONE have any experience getting IPA to work with FIPS?
>>
>> We're trying desperately to get this going, as we have some requirements
>> that the Identity Management Tool we choose must be FIPS 140-2 compliant.
> 
> No, it doesn't work in FIPS mode yet. If you open a support case with
> Red Hat your case can be added to
> https://bugzilla.redhat.com/show_bug.cgi?id=1125174
> 
> While most, if not all, of the individual components can run in FIPS
> mode there are a lot of moving parts to coordinate to ensure they comply
> with the FIPS Security Policy and to handle some corner cases in the
> management framework.
> 
> 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] Can we disable HTTP TRACE / TRACK Method in IPA

[Martin Kosek]

On 07/15/2016 08:17 AM, Zeal Vora wrote:
> Hi
> 
> In our Internal VA, Vulnerability Assessment tools generates the HTTP TRACE / 
> TRACK method in IPA as a medium based vulnerability.
> 
> Is there a need to allow those two methods in IPA ?
> 
> If not, what is the optimal way to disable those methods ?
> 
> 
> Thanks,
> Zeal

Hello Zeal,

I think it should be safe disabling these methods in FreeIPA Apache
configuration - I do not think FreeIPA uses them.

I added your remark to
https://fedorahosted.org/freeipa/ticket/4431
This is where we plan to harden the FreeIPA Apache instance. If you have any
other ideas that were not captured in the ticket yet, please feel free to share
them with us!

Thanks,
Martin

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

Re: [Freeipa-users] Replication Agreement issues noticed with repl-monitor.pl

[Martin Kosek]

You should be able to succeed with "ipa-replica-manage del "
and --force/--cleanup flags:

$ man ipa-replica-manage
...
   -c, --cleanup
  When  deleting  a  master with the --force flag, remove leftover
  references to an already deleted master.
...

Martin

On 07/14/2016 05:35 PM, Devin Acosta wrote:
> ipa01-jap was a host that is no more, is there a simple way to clear these 
> replication agreements to clean it up?
> 
> On Thu, Jul 14, 2016 at 7:14 AM, Petr Vobornik  <mailto:pvobo...@redhat.com>> wrote:
> 
> On 07/14/2016 12:57 PM, Martin Kosek wrote:
>  > On 07/13/2016 04:24 AM, Devin Acosta wrote:
>  >>
>  >> I was trying to create another Replica but then noticed it was
> constantly having
>  >> issues trying to finish the joining of the replication. I then ran the
> command:
>  >> repl-monitor.pl <http://repl-monitor.pl> <http://repl-monitor.pl>, It
> appears i have several replicaid's
>  >> and they seem to be having issues, wondering if this is adding to my 
> issue.
>  >>
>  >> Anyone know how I can resolve this issue and clean up the 
> replication???
>  >>
>  >> See attached Screenshot.
>  >
>  > I wonder if cleaning RUVs help:
>  >
>  >
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/trouble-replica.html#trouble-repl-cleanruv
>  >
> 
> dangling RUVs
> 
> 1. "Can't acquire busy replica"
> seems OK if it disappears after a while.
> 
> 2. "1 Unable to acquire replicaLDAP error: Can't contact LDAP"
> Probably worth investigating if ipa01-
> i2x.rsinc.local:389 and ipa01-
> jap.rsinc.local:389 still exist. If not then there is probably a
> dangling replication agreement for o=ipaca suffix.
> 
> --
> 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] Replication Agreement issues noticed with repl-monitor.pl

[Martin Kosek]

On 07/13/2016 04:24 AM, Devin Acosta wrote:
> 
> I was trying to create another Replica but then noticed it was constantly 
> having 
> issues trying to finish the joining of the replication. I then ran the 
> command: 
> repl-monitor.pl , It appears i have several 
> replicaid's 
> and they seem to be having issues, wondering if this is adding to my issue.
> 
> Anyone know how I can resolve this issue and clean up the replication???
> 
> See attached Screenshot.

I wonder if cleaning RUVs help:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/trouble-replica.html#trouble-repl-cleanruv

-- 
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] Deny bind for external LDAP if password is expired

[Martin Kosek]

On 07/07/2016 05:19 PM, Prashant Bapat wrote:
> Anyone ?!
> 
> On 6 July 2016 at 22:36, Prashant Bapat  > wrote:
> 
> Hi,
> 
> We are using FreeIPA's LDAP as the base for user authentication in a
> different application. So far I have created a sysaccount which does the
> lookup etc for a user and things are working as expected. I'm even able to
> use OTP from the external app.
> 
> One problem I'm struggling to fix is the expired passwords. Is there a way
> to deny bind to LDAP only from this application? Obviously the user would
> need to go to IPA's web UI and reset his password there.
> 
> I came across this ticket https://fedorahosted.org/freeipa/ticket/1539 but
> looks like this is an old one.
> 
> Thanks.
> --Prashant

Hello Prashant,

https://fedorahosted.org/freeipa/ticket/1539 seems to be the right ticket, if
you want users with expired passwords to be denied, but it was not implemented
yet. Help welcome!

As a workaround, I assume you could simply leverage Kerberos for authentication
- it does respect expired passwords. We have advise on how to integrate that to
external web applications here:

http://www.freeipa.org/page/Web_App_Authentication

Martin

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

Re: [Freeipa-users] Replication time and relation to cache size

[Martin Kosek]

On 06/21/2016 05:19 PM, Ash Alam wrote:
> anyone have any thoughts on this?
> 
> Thank You
> 
> On Fri, Jun 10, 2016 at 2:59 PM, Ash Alam  > wrote:
> 
> Hello
> 
> I have been going through the lists but i have not found the answer i am
> looking for. I am seeing few issues for which i am looking for some
> clarification.
> 
> 1. What is the relationship between replication time and cache size?
> 
> - I am noticing that it's taking up to 5 minutes for some things to
> replication when change is made on one node and there are two additional
> masters. The ipa nodes are all virtual machines within the same cluster.
> 
> - WARNING: changelog: entry cache size 2097152B is less than db size
> 116154368B; We recommend to increase the entry cache size 
> nsslapd-cachememsize.
> 
> - I don't understand the cache size. Would't increasing it cause the same
> issue when we hit the new limit?
> 
> - connection - conn=3779 fd=175 Incoming BER Element was 3 bytes, max
> allowable is 209715200 bytes. Change the nsslapd-maxbersize attribute in
> cn=config to increase.
> 
> 
> 2. Is there a definitive solution to this error? This seems to pop up 
> every
> so often.
> 
> - NSMMReplicationPlugin - agmt="cn=meToipa009.pp" (ipa009:389): Warning:
> Attempting to release replica, but unable to receive endReplication 
> extended

Hi Ash,

I see no reply, let me try and hook Thierry/Ludwig, they should know more.

Martin

P.S. sorry for the delay, most of FreeIPA core developers were focused on
getting FreeIPA 4.4 out of the door.

-- 
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 automatically group new users under Stage Users when users are synced from AD

[Martin Kosek]

On 06/26/2016 06:57 PM, Supratik Goswami wrote:
> Hi
> 
> I am using ipa-server-4.2.0  in my environment, it is having winsync 
> agreement 
> with the AD server.
> I want to move all new users to "Stage Users" state automatically when they 
> are 
> synced from the AD, can anyone please guide me on how to achieve it?
> 
> Any help is highly appreciated.
> 
> -- 
> Warm Regards

Hi Supratik,

This is not possible at the moment - this is an RFE. Please feel free to file
an upstream ticket, I assume it should be doable. Please just note you would
probably need to contribute patches to make this working as winsync is not a
priority for most of the core developers, AD Trust is.

Thanks,
Martin

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

Re: [Freeipa-users] Password sync settings not working

[Martin Kosek]

Good! Thanks for confirmation (I suspected PEBKAC, thus my questions).

Martin

On 07/02/2016 10:01 PM, Joshua J. Kugler wrote:
> Thanks. In a case of extreme PEBKAC, I had copied the example and failed to 
> update the DN.  It works now.
> 
> j
> 
> 
> On Monday, June 13, 2016 09:35:53 Martin Kosek wrote:
>> On 06/10/2016 01:59 AM, Joshua J. Kugler wrote:
>>> Howdy!
>>>
>>> We are trying to set up password sync.  I have read this:
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/h
>>> tml-single/Windows_Integration_Guide/index.html#password-sync
>>>
>>> I have added that attribute:
>>> echo -e 'dn: cn=ipa_pwd_extop,cn=plugins,cn=config\nchangetype:
>>> modify\nadd: passSyncManagersDNs\npassSyncManagersDNs:
>>> uid=admin,cn=users,cn=accounts,dc=example,dc=com' | ldapmodify -x -D
>>> 'cn=Directory Manager' -w {{ ipaserver_dir_admin_password }} -h localhost
>>> -p 389
>>>
>>> However, when I reset a password as the 'admin' user, the user's password
>>> is still set to expired.  This is CentOS 7 with the latest FreeIPA there.
>>>
>>> What might I be missing?
>>
>> I would try to double check that the passSyncManagersDNs is indeed filled
>> properly in the plugin configuration. Base ldapsearch will help.
>>
>> Then I would also recommend checking your global password policy "ipa
>> pwpolicy-show" to make sure that you for example do not have the password
>> max life set to 0, which would cause this behavior in current FreeIPA
>> version.
>>
>> Martin
> 

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

Re: [Freeipa-users] Read-only access to enforce OTP

[Martin Kosek]

On 06/16/2016 11:00 AM, Prashant Bapat wrote:
> Hi,
> 
> I'm writing a small script which will scan all the users and check if each 
> one 
> has setup an OTP. It will send out an email to the user if OTP is missing.
> 
> I added a new entry / 
> uid=otp-check-ro,cn=sysaccounts,cn=etc,dc=example,dc=com/. 
> Problem is I'm able to read all the users attributes but not able to read 
> anything under /cn=otp,dc=example,dc=com/ tree.
> 
> What are the permissions or ACI I need to add to give read-only access to 
> this user?
> 
> Thanks.
> --Prashant
> 
> 
> 

I would recommend creating read permission for the tree & attribute/objects you
need to allow. Doc is here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/defining-roles.html#creating-perms-cli

You cannot apply this permission to system user with API, you would need to use
ldapmodify and add the right membership. But you could create service account
(service-add), create keytab for the authentication and then assign it a role
that has a privilege that has your permission. I hope that makes sense.

Martin

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

Re: [Freeipa-users] Unable to install replica using replica file

[Martin Kosek]

On 06/15/2016 06:40 AM, Abhijeet Kasurde wrote:
> Hi All,
> 
> I am creating master replica setup using following commands and getting error
> on replica server
> 
> 2016-06-15T03:53:31Z DEBUG The ipa-replica-install command failed, exception:
> NetworkError: cannot connect to 'ldaps://dhcp201-141.testrelm.test:636': TLS
> error -8157:Certificate extension not found.
> 
> Can anyone explain me what does this error is trying to say ?
> 
> I am performing following steps
> 
> $ mkdir /tmp/nssdb
> $ vim /tmp/nssdb/password.txt
> $ vim /tmp/nssdb/noise.txt
> $ certutil -d /tmp/nssdb/ -N -f /tmp/nssdb/password.txt
> $ certutil -d /tmp/nssdb -S -n ca -s cn=Test_CA -x -t CTu,Cu,Cu -g 2048 -v 60
> -z /tmp/nssdb/noise.txt -2 -f /tmp/nssdb/passwd.txt
> $ certutil -d /tmp/nssdb -S -n server -s cn=dhcp201-172.testrelm.test -t ,, -z
> /tmp/nssdb/noise.txt -c ca -f /tmp/nssdb/passwd.txt
> $ /usr/bin/pk12util -o /tmp/nssdb/server.p12 -n server -d /tmp/nssdb -k
> /tmp/nssdb/passwd.txt -W Secret123
> $ ipa-server-install --http-cert-file /tmp/nssdb/server.p12 --dirsrv-cert-file
> /tmp/nssdb/server.p12 --ip-address 10.65.210.89 -r TESTRELM.TEST -p Secret123
> -a Secret123 --setup-dns --forwarder 10.11.5.19 --http-pin Secret123
> --dirsrv-pin Secret123 -U
> $ certutil -d /tmp/nssdb -S -n ca -s cn=Test_CA -x -t CTu,Cu,Cu -g 2048 -v 60
> -z /tmp/nssdb/noise.txt -2 -f /tmp/nssdb/passwd.txt -m 3
> $ certutil -d /tmp/nssdb -S -n replica -s cn=dhcp201-141.testrelm.test -t ,, 
> -z
> /tmp/nssdb/noise.txt -c ca -f /tmp/nssdb/passwd.txt -m 4
> $ /usr/bin/pk12util -o /tmp/nssdb/replica.p12 -n replica -d /tmp/nssdb -k
> /tmp/nssdb/passwd.txt -W Secret123·
> $ ipa-replica-prepare dhcp201-141.testrelm.test --http_pkcs12
> /tmp/nssdb/replica.p12 --http_pin Secret123 --dirsrv_pkcs12
> /tmp/nssdb/replica.p12 --dirsrv_pin Secret123 --ip-address 10.65.210.91
> --reverse-zone=210.65.10.in-addr.arpa.
> $ scp /var/lib/ipa/replica-info-dhcp201-141.testrelm.test.gpg
> r...@dhcp201-141.testrelm.test:/root/
> 
> Attaching console.log and replicainstall.log

CCing Jan, he may have some CA-less related commands handy (or know if
installer is lacking some check).

Martin

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

Re: [Freeipa-users] Best practices on securing freeipa

[Martin Kosek]

On 06/14/2016 07:51 PM, Danila Ladner wrote:
> Greetings Folks.
> I could not find any information on best practices of securing free ipa 
> servers 
> and its replicas.
> Since the hosts become an important part of IT IM infrastructure, wanted to 
> see 
> if anyone can point me to the right sources beyond default configuration.
> Thank you,
> Danila

Hello Danila,

I am now not sure if we have something like that. We are working on making
FreeIPA secure in the default configuration :-)

In any case, this is most complete guide for configuring FreeIPA that I know 
about:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html

Martin

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

Re: [Freeipa-users] Password sync settings not working

[Martin Kosek]

On 06/10/2016 01:59 AM, Joshua J. Kugler wrote:
> Howdy!
> 
> We are trying to set up password sync.  I have read this:
> 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#password-sync
> 
> I have added that attribute:
> echo -e 'dn: cn=ipa_pwd_extop,cn=plugins,cn=config\nchangetype: modify\nadd: 
> passSyncManagersDNs\npassSyncManagersDNs: 
> uid=admin,cn=users,cn=accounts,dc=example,dc=com' | ldapmodify -x -D 
> 'cn=Directory Manager' -w {{ ipaserver_dir_admin_password }} -h localhost -p 
> 389
> 
> However, when I reset a password as the 'admin' user, the user's password is 
> still set to expired.  This is CentOS 7 with the latest FreeIPA there.
> 
> What might I be missing?

I would try to double check that the passSyncManagersDNs is indeed filled
properly in the plugin configuration. Base ldapsearch will help.

Then I would also recommend checking your global password policy "ipa
pwpolicy-show" to make sure that you for example do not have the password max
life set to 0, which would cause this behavior in current FreeIPA version.

Martin

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

Re: [Freeipa-users] FreeIPA 4.4

[Martin Kosek]

On 06/08/2016 12:18 PM, Winfried de Heiden wrote:
> Hi all,
> 
> Any news/progress about FreeIPA 4.4?
> 
> On http://www.freeipa.org/page/Roadmap: *FreeIPA 4.4*: feature release. 
> Release 
> planned for end of May 2016.
> 
> Any updated release date...?

The new estimate is rather June, there was more development needed than
expected to deliver some of the planned features like the FreeIPA Thin Client
refactoring (required for API versioning).

I updated the Roadmap page to reflect the state better.

Thanks!
Martin

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

Re: [Freeipa-users] Replica without CA: implications?

[Martin Kosek]

On 06/08/2016 11:05 AM, Cal Sawyer wrote:
> 
> On 08/06/16 09:23, Martin Kosek wrote:
>> On 06/07/2016 04:10 PM, Cal Sawyer wrote:
>> ...
>>> I found that installing a replica with firewalld enabled would consistently
>>> fail
>>> during initial replication.  Disabling firewalld always allowed replication 
>>> and
>>> later stages to complete
>>>
>>> [24/38]: setting up initial replication
>>>  Starting replication, please wait until this has completed.
>>>
>>>  [ipa.localdomain.local] reports: Update failed! Status: [-1  - LDAP 
>>> error:
>>>  Can't contact LDAP server]
>> This is strange. ipa-replica-install should have run the conncheck to exactly
>> prevent issues like this. Did you by any chance run ipa-replica-install with
>> --skip-conncheck option?
>>
> Yes, i did.

There you go - pure PEBKAC :-)

> Why i can't recall now but i just started using it. Once i'd
> discovered firewalld was causing the connection problem, i neglected to stop
> using it
> Of course, once a replica is installed and working, there's little cause to
> want to redo it to test conncheck's effectiveness.  Might throw together
> another, though, just to put my mind at ease

For the record, you can also run ipa-replica-conncheck outside 
ipa-replica-install.

> 
>>> The first master and all replicas are all CentOS Linux release 7.2.1511 
>>> (Core)
>>> with ipa-server-4.2.0-15.0.1.el7
>>>
>>>
>>> One other thing.  if, during ipa-replica-install,+ you choose the default
>>> answer
>>> to the following:
>>>
>>> Existing BIND configuration detected, overwrite? [no]:
>>> ipa.ipapython.install.cli.install_tool(Replica): ERRORAborting
>>> installation.
>>>
>>> Not sure if that is intended?  Which BIND configuration is being detected?
>> This should be only trigged if you install replica with DNS (--setup-dns)
>>
> Sorry - yes, i did use --setup-dns .  I might have bothered to include the
> ipa-replica-install command line i used.  Still, that is what i got if i
> answered No to the question.
> Seems like it's the wrong default answer to the question in a --setup-dns
> scenario?

Yes. This means you do not want installer to modify and update named.conf for
FreeIPA, i.e. it cannot install FreeIPA DNS module and has to abort.

>>> Anyhow, up and running with 4 replicas, 2 of which will be split off to a
>>> failover instance of ESXi in the future.  When it works, it's a joy
>>>
>>> Now back to getting these Mac clients to play nicely with IPA ...
>>>
>>> thanks for the help and advice
>> Thanks for sharing the results.
>> Martin
>>
> 

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

Re: [Freeipa-users] sessions failing when using different hostname

[Martin Kosek]

On 06/08/2016 09:42 AM, Jan Pazdziora wrote:
> On Wed, Jun 08, 2016 at 09:29:09AM +0200, Martin Kosek wrote:
>> On 06/01/2016 07:48 PM, Anthony Clark wrote:
>>>
>>> I'm somewhat at a loss to debug this further.  I was wondering if the 
>>> session 
>>> storage is somehow bound to the original host name.  Is there a way to 
>>> check 
>>> and/or configure this?
>>>
>>> Alternatively is there a guide out there for enabling additional host names 
>>> for 
>>> the web UI in FreeIPA?
>>
>> Good question. I see there was no reply for this thread (note that most of 
>> the
>> developers are finishing FreeIPA 4.4 release) yet, CCing Petr to advise.
> 
> Karl F. asked similar question a day later and I've provided description
> for this requirement at
> 
>   https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name
> 
> The setup does not work all that well for Anthony as mentioned in the
> other thread but we will debug it from here.

Great, thanks! Added the links to
http://www.freeipa.org/page/HowTos#Web_Infrastructure

Martin

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

Re: [Freeipa-users] [FreeIPA 4.3.0] Limits exceeded for this query

[Martin Kosek]

On 06/07/2016 09:08 PM, Nathan Peters wrote:
> I get this when doing almost anything on only one of my Fedora 23 FreeIPA 
> 4.3.0 
> servers.  The rest work fine.
> 
> This server also tends to crash quite a bit and the others do not.
> 
> Any tips on what I should be looking for or how to fix that ?
> 
> Some operations failed.
> 
> Hide details 
> 
> ·limits exceeded for this query
> 
> Nathan Peters

CCing Petr. I wonder if this is related to
https://fedorahosted.org/freeipa/ticket/5833

Martin

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

Re: [Freeipa-users] How to get FreeIPA feature requests ack'd?

[Martin Kosek]

On 06/07/2016 05:22 PM, Cal Sawyer wrote:
> Hello
> 
> The RH Bugzilla is pretty much unnavigable by anyone who doesn't know the 
> magic
> words, so i'm asking here. Apologies in advance if misdirected.

Hi Cal,

I updated FreeIPA Trac front page, to help you (and others) more with filing
bugs against FreeIPA, whether it is about downstream (RHEL, Fedora) bugs or
upstream tickets:

https://fedorahosted.org/freeipa/wiki

Bugzilla links already contain direct links with product a component specified
to make your job easier. But if you do not have RHEL subscription or bug is
Fedora specific, filing Trac ticket is the best first step to do.

> The Web UI has a couple of fairly annoying (sorry) deficiencies:
> 
> - unable to sort on columns, eg: In DNS Zones, the sort is on hostname, making
> it difficult to locate holes in a network range. This is easy in BIND flat 
> zone
> files, which by convention are usually organised by IP address
> - of course, sorting on IP address needs to be done like mySQL's ORDER BY
> INET_ATON(ip) to prevent what i like to call "Mac-style" ordering of IP
> addresses (1, 10 100, 2)
> - record and subtree cloning would be a terrific feature when working with
> automount maps and sudo objects that are fiddly to edit in the UI. 
> Essentially,
> what phpldapadmin allows

Please file upstream ticket(s) for these. If you want to speed up resolution of
the feature requests or bug reports, the most effective way is to provide
patches or other help as there are thousands of requests filed against FreeIPA,
but only limited number of developers working on them.

Thanks,
Martin

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

Re: [Freeipa-users] Replica without CA: implications?

[Martin Kosek]

On 06/07/2016 04:10 PM, Cal Sawyer wrote:
...
> I found that installing a replica with firewalld enabled would consistently 
> fail 
> during initial replication.  Disabling firewalld always allowed replication 
> and 
> later stages to complete
> 
>[24/38]: setting up initial replication
> Starting replication, please wait until this has completed.
> 
> [ipa.localdomain.local] reports: Update failed! Status: [-1  - LDAP error:
> Can't contact LDAP server]

This is strange. ipa-replica-install should have run the conncheck to exactly
prevent issues like this. Did you by any chance run ipa-replica-install with
--skip-conncheck option?

> The first master and all replicas are all CentOS Linux release 7.2.1511 
> (Core) 
> with ipa-server-4.2.0-15.0.1.el7
> 
> 
> One other thing.  if, during ipa-replica-install,+ you choose the default 
> answer 
> to the following:
> 
> Existing BIND configuration detected, overwrite? [no]:
> ipa.ipapython.install.cli.install_tool(Replica): ERRORAborting 
> installation.
> 
> Not sure if that is intended?  Which BIND configuration is being detected?

This should be only trigged if you install replica with DNS (--setup-dns)

> Anyhow, up and running with 4 replicas, 2 of which will be split off to a 
> failover instance of ESXi in the future.  When it works, it's a joy
> 
> Now back to getting these Mac clients to play nicely with IPA ...
> 
> thanks for the help and advice

Thanks for sharing the results.
Martin

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

Re: [Freeipa-users] sessions failing when using different hostname

[Martin Kosek]

On 06/01/2016 07:48 PM, Anthony Clark wrote:
> Hello All,
> 
> I've been asked to allow access to our FreeIPA web UI from a more user 
> friendly 
> url than I'm currently using.  So I've set up a CNAME password.example.com 
>  for ns01.example.com 
> 
> At the moment, if I go to the real hostname of the FreeIPA server 
> (ns01.example.com ), everything works.
> 
> If I go to the new "friendly" url (password.example.com 
> ) then upon login I get a "your session has 
> expired 
> please re-login" message.
> 
> Setting debug to true in /etc/ipa/server.conf shows me that the server keeps 
> using new session IDs.  (Host and user names changed to protect the innocent)
> 
> - /var/log/httpd/error_log -
> [Wed Jun 01 17:11:06.237363 2016] [:error] [pid 31491] ipa: DEBUG: WSGI 
> wsgi_dispatch.__call__:
> [Wed Jun 01 17:11:06.237533 2016] [:error] [pid 31491] ipa: DEBUG: WSGI 
> jsonserver_session.__call__:
> [Wed Jun 01 17:11:06.237944 2016] [:error] [pid 31491] ipa: DEBUG: no session 
> cookie found
> [Wed Jun 01 17:11:06.239009 2016] [:error] [pid 31491] ipa: DEBUG: no session 
> id 
> in request, generating empty session data with 
> id=d5bc1c4cab8d3bfaee63b84805147995
> [Wed Jun 01 17:11:06.239466 2016] [:error] [pid 31491] ipa: DEBUG: store 
> session: session_id=d5bc1c4cab8d3bfaee63b84805147995 
> start_timestamp=2016-06-01T17:11:06 access_timestamp=2016-06-01T17:11:06 
> expiration_timestamp=1970-01-01T00:00:00
> [Wed Jun 01 17:11:06.241052 2016] [:error] [pid 31491] ipa: DEBUG: 
> jsonserver_session.__call__: session_id=d5bc1c4cab8d3bfaee63b84805147995 
> start_timestamp=2016-06-01T17:11:06 access_timestamp=2016-06-01T17:11:06 
> expiration_timestamp=1970-01-01T00:00:00
> [Wed Jun 01 17:11:06.241186 2016] [:error] [pid 31491] ipa: DEBUG: no ccache, 
> need login
> [Wed Jun 01 17:11:06.241294 2016] [:error] [pid 31491] ipa: DEBUG: 
> jsonserver_session: 401 Unauthorized need login
> [Wed Jun 01 17:11:24.956791 2016] [:error] [pid 31492] ipa: DEBUG: WSGI 
> wsgi_dispatch.__call__:
> [Wed Jun 01 17:11:24.956992 2016] [:error] [pid 31492] ipa: DEBUG: WSGI 
> login_password.__call__:
> [Wed Jun 01 17:11:24.957381 2016] [:error] [pid 31492] ipa: DEBUG: Obtaining 
> armor ccache: principal=HTTP/ns01.example@example.com 
>  keytab=/etc/httpd/conf/ipa.keytab 
> ccache=/var/run/ipa_memcached/krbcc_A_aclark
> [Wed Jun 01 17:11:24.957519 2016] [:error] [pid 31492] ipa: DEBUG: 
> Initializing 
> principal HTTP/ns01.example@example.com 
>  using keytab /etc/httpd/conf/ipa.keytab
> [Wed Jun 01 17:11:24.957633 2016] [:error] [pid 31492] ipa: DEBUG: using 
> ccache 
> /var/run/ipa_memcached/krbcc_A_aclark
> [Wed Jun 01 17:11:24.998328 2016] [:error] [pid 31492] ipa: DEBUG: Attempt 
> 1/1: 
> success
> [Wed Jun 01 17:11:24.998531 2016] [:error] [pid 31492] ipa: DEBUG: 
> Initializing 
> principal acl...@example.com  using password
> [Wed Jun 01 17:11:24.998684 2016] [:error] [pid 31492] ipa: DEBUG: Using 
> armor 
> ccache /var/run/ipa_memcached/krbcc_A_aclark for FAST webauth
> [Wed Jun 01 17:11:24.998865 2016] [:error] [pid 31492] ipa: DEBUG: Starting 
> external process
> [Wed Jun 01 17:11:24.998984 2016] [:error] [pid 31492] ipa: DEBUG: 
> args='/usr/bin/kinit' 'acl...@example.com ' '-c' 
> 'FILE:/var/run/ipa_memcached/krbcc_31492' '-T' 
> '/var/run/ipa_memcached/krbcc_A_aclark'
> [Wed Jun 01 17:11:26.079200 2016] [:error] [pid 31492] ipa: DEBUG: Process 
> finished, return code=0
> [Wed Jun 01 17:11:26.079384 2016] [:error] [pid 31492] ipa: DEBUG: 
> stdout=Password for acl...@example.com :
> [Wed Jun 01 17:11:26.079399 2016] [:error] [pid 31492]
> [Wed Jun 01 17:11:26.079483 2016] [:error] [pid 31492] ipa: DEBUG: stderr=
> [Wed Jun 01 17:11:26.079680 2016] [:error] [pid 31492] ipa: DEBUG: Cleanup 
> the 
> armor ccache
> [Wed Jun 01 17:11:26.079871 2016] [:error] [pid 31492] ipa: DEBUG: Starting 
> external process
> [Wed Jun 01 17:11:26.079983 2016] [:error] [pid 31492] ipa: DEBUG: 
> args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_aclark'
> [Wed Jun 01 17:11:26.093954 2016] [:error] [pid 31492] ipa: DEBUG: Process 
> finished, return code=0
> [Wed Jun 01 17:11:26.094113 2016] [:error] [pid 31492] ipa: DEBUG: stdout=
> [Wed Jun 01 17:11:26.094210 2016] [:error] [pid 31492] ipa: DEBUG: stderr=
> [Wed Jun 01 17:11:26.094809 2016] [:error] [pid 31492] ipa: DEBUG: no session 
> cookie found
> [Wed Jun 01 17:11:26.095877 2016] [:error] [pid 31492] ipa: DEBUG: no session 
> id 
> in request, generating empty session data with 
> id=7ab08ba17d30883cff480af9e923cf82
> [Wed Jun 01 17:11:26.096132 2016] [:error] [pid 31492] ipa: DEBUG: store 
> session: session_id=7ab08ba17d30883cff480af9e923cf82 
> start_timestamp=2016-06-01T17:11

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

[Martin Kosek]

On 05/30/2016 10:53 PM, Prasun Gera wrote:
> 
> 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.

If you use only users, groups and passwords, the migration may actually not be
that painful as you can migrate with "ipa migrate-ds" command as advised in
http://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA
and then enrolling your clients with the new FreeIPA realm. We have a RFE for a
more complete migration tracked
https://fedorahosted.org/freeipa/ticket/3656
that was being worked on as a thesis.

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

Certificate Profiles is a standard feature in FreeIPA 4.2+. Profile edit is not
that straightforward, but if you download current one for the profile, you
should be able to figure out what line to edit (and then you just upload the
profile again).

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

Yeah, browsers generally not care about CRL/OCSP unless explicitly enabled. I
know that at least Firefox has a setting to always check for certificate 
validity.

> 
> 
> > On Fri, May 27, 2016 at 10:19 PM, Rob Crittenden  
>  > >> 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 
> 
>  > ). 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
> mailto:prasun.g...@gmail.com>
>  > >
> > 
>  >
> >  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 
> mailto:prasun.g...@gmail.com>
> > >
>  >   
> 

Re: [Freeipa-users] Centos 7.2 ipa-backup failure

[Martin Kosek]

On 05/30/2016 06:57 PM, Ken Bass wrote:
> On 05/30/2016 10:32 AM, Martin Kosek wrote:
>> On 05/29/2016 05:33 PM, Ken Bass wrote:
>>> Today I tried my very first ipa-backup attempt. The command reported 'The
>>> ipa-backup command was successful'
>>>
>>> YET  I saw:
>>>
>>> /usr/sbin/db2ldif: line 157: 22567 Segmentation fault /usr/sbin/ns-slapd
>>> db2ldif -D /etc/dirsrv/slapd-DOMAIN-NET -n userRoot -a "/var/l
>>> ib/dirsrv/slapd-DOMAIN-NET/ldif/DOMAIN-NET-userRoot.ldif" -r
>>>
>>> I am running Centos 7.2. After googling, I did find -
>>> https://fedorahosted.org/freeipa/ticket/5571
>>> https://fedorahosted.org/389/ticket/48388
>>>
>>> How am I supposed to backup this box? I want to run the backup-script 
>>> nightly
>>> to generate the tarball so I can use another script to backup it up along 
>>> with
>>> other stuff. It is a small system with no replication.
>>>
>>> As a Centos 7.2 user am I just out of luck since it appears the various 
>>> bugs I
>>> am encountering with this software are not being fixed except in newer 
>>> versions
>>> of freeipa and sssd which are not available
>>> via the standard repos?
>> Hello Ken,
>>
>> I am sorry to hear about your trouble. The standard way for people with RHEL
>> subscription is to request a RHEL fix from support, but if you do not have 
>> it,
>> you would need to deal with it other way.
> Correct, I do not have a RHEL subscription. However my justification for using
> Centos 7.2, rather than Fedora,
> was that I would be using a production quality product. The same as the 'big
> guys' so to speak.

Right.

> So when I am running into
> a bunch of issues it makes me wonder how this stuff got through Q&A in the
> first place.

You obviously must be hitting some scenario or have a configuration environment
that was not tested. Filing a RHEL Bug should help also to ensure that this
scenario is tested.

>> As this is a DS issue (linked from FreeIPA ticket), you can try raising
>> awareness in RHEL-7 product of the 389-ds-base and ask for backport of this
>> issue to RHEL-7.2.x stream.
> 
>  I dont think it is solely a DS issue. The ipa-backup script is reporting
> command successful when something internal is seg faulting.
> That would seem like someone is not checking a return code in the ipa-backup
> script. At least the ipa-backup script should be reporting a failure since I
> assume the backup is incomplete.

That *is* a good point and is worth filing upstream ticket
https://fedorahosted.org/freeipa/newticket

If you can also help FreeIPA with a code contribution, it would help project
immensely as there is a lots of tickets...

>> Alternatively, projects may have own CentOS repos
>> where they can publish builds of upcoming releases, like FreeIPA has:
>>
>> https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-3-centos-7/
> 
> I had thought about using that, but it warns it is not for production, and 
> with
> the number of issues I have encountered in the production
> version, I worry that the copr version would be even worse, and that if there
> are any issues the response will just be don't use it for production.

It is true that these packages are provided as builds of FreeIPA upstream
project, with "community support", i.e. this mailing list and voluntary based
help. RHEL is officially QE'd and supported, so the base CentOS packages should
be more stable, yes - though with lower amount of updates, given the QE and
support related processes. It is a trade-off as usual.

> Do you know how stable the software being fed to the copr is? While perhaps
> overkill, I am only using this for 2 boxes with 2 users -- mainly for the 2FA
> component. I am not doing anything
> fancy like replication, etc. I had replaced some custom radius server code and
> openldap stuff with freeIPA since it helped with enrolling tokens via freeOTP
> and such. The freeIPA is better
> integrated into sssd than my custom solution (though I had to install sssd 
> from
> copr due to basic bugs in the sudo 2FA code).

It is hard to quantify stability, so I would go with "more stable than git
builds as it goes through Upstream QE test suite, less stable than RHEL bits -
that are production ready".

Martin

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

Re: [Freeipa-users] Unable to access to web ui

[Martin Kosek]

On 05/30/2016 04:36 PM, Martin Basti wrote:
> 
> 
> On 30.05.2016 14:20, seli irithyl wrote:
>> Hi,
>>
>> Since last update, I'am unable to log in to web ui with FF (e.g. blank page)
>> Any idea where too look for ?
>>
>> Best regards,
>>
>> Seli
>>
>>
>>
>>
>>
> Hello,
> 
> can you provide version of the freeIPA, firefox. Does it work from different 
> browser? does it work from private mode?

+ does [CTRL]+F5 helps? Do advise in
http://www.freeipa.org/page/Troubleshooting#Web_UI
help?

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

Re: [Freeipa-users] Install best practice -

[Martin Kosek]

On 05/29/2016 07:11 PM, Ben .T.George wrote:
> Hi
> 
> I would like to know how can i proceed with best practices
> 
> My AD domain is : corp.examle.com.kw 
> My DNS (appliances ) : kw.test.com 
> 
> All my clients are pointed to kw.test.com  including AD.
> 
> How can i proceed with Free IPA installation? where i need to manage DNS of 
> freeipa master server?
> 
> 
> creating new DNS zone in kw.test.com  will be little bit 
> difficult.
> 
> which will be best configuration with minimal changes in existing setup.

The best resources for this topic is probably

http://www.freeipa.org/page/Deployment_Recommendations#Considerations_for_Active_Directory_integration_on_DNS_level

This may be related:
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain

Martin

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

Re: [Freeipa-users] Centos 7.2 ipa-backup failure

[Martin Kosek]

On 05/29/2016 05:33 PM, Ken Bass wrote:
> Today I tried my very first ipa-backup attempt. The command reported 'The
> ipa-backup command was successful'
> 
> YET  I saw:
> 
> /usr/sbin/db2ldif: line 157: 22567 Segmentation fault /usr/sbin/ns-slapd
> db2ldif -D /etc/dirsrv/slapd-DOMAIN-NET -n userRoot -a "/var/l
> ib/dirsrv/slapd-DOMAIN-NET/ldif/DOMAIN-NET-userRoot.ldif" -r
> 
> I am running Centos 7.2. After googling, I did find -
> https://fedorahosted.org/freeipa/ticket/5571
> https://fedorahosted.org/389/ticket/48388
> 
> How am I supposed to backup this box? I want to run the backup-script nightly
> to generate the tarball so I can use another script to backup it up along with
> other stuff. It is a small system with no replication.
> 
> As a Centos 7.2 user am I just out of luck since it appears the various bugs I
> am encountering with this software are not being fixed except in newer 
> versions
> of freeipa and sssd which are not available
> via the standard repos?

Hello Ken,

I am sorry to hear about your trouble. The standard way for people with RHEL
subscription is to request a RHEL fix from support, but if you do not have it,
you would need to deal with it other way.

As this is a DS issue (linked from FreeIPA ticket), you can try raising
awareness in RHEL-7 product of the 389-ds-base and ask for backport of this
issue to RHEL-7.2.x stream. Alternatively, projects may have own CentOS repos
where they can publish builds of upcoming releases, like FreeIPA has:

https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-3-centos-7/

Martin

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

Re: [Freeipa-users] EXAMPLE.COM IPA CA Import /etc/httpd/alias

[Martin Kosek]

On 05/29/2016 09:18 AM, Günther J. Niederwimmer wrote:
> Hello
> I found any Help for the IPA Certificate but I found no way to import the IPA 
> CA ?
> I like to create a webserver with a owncloud virtualhost and other..
> 
> But it is for me not possible to create the /etc/httpd/alias correct ?
> 
> I found this in IPC DOCS
>  
> certutil -A -d . -n 'EXAMPLE.COM IPA CA' -t CT,, -a < /etc/ipa/ca.crt
> 
> but with this command line I have a Error /etc/ipa/ca.crt have wrong format ?
> 
> Have any a link with a working example

I have hard time understanding what the use case is, but it looks like you are
looking for information in

http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure

Martin

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

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

[Martin Kosek]

On 05/28/2016 05:30 AM, Prasun Gera wrote:
> 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.

ipa-ca.$DOMAIN OCSP/CRL is currently hardcoded in the Certificate Profiles, you
would need to edit them with different value (which may then make FreeIPA
upgrades funny).

I still think the easiest solution may be to simply request DNS change in your
external DNS and create the ipa-ca DNS record - it is a simple list of IPA CA
server's IP addresses.

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

This feature uses the primary FreeIPA DNS domain, which is derived from it's
realm. This is the same approach as with AD. If you do not have access to this
DNS domain, I expect you will have trouble if you want to for example start
using AD Trusts which expects working primary DNS domain with proper SRV
records (FreeIPA servers can still live in other domain though).

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

> On Fri, May 27, 2016 at 10:19 PM, Rob Crittenden  > 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 
> ). 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  
> >> 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 
>  
>  >> 
> 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 

Re: [Freeipa-users] Adding groupOfUniqueNames to all freeipa replicas for Zenoss LDAP authentication

[Martin Kosek]

On 05/27/2016 03:17 PM, Bob Hinton wrote:
> Hi Martin,
> 
> On 27/05/2016 14:01, Martin Kosek wrote:
>> On 05/25/2016 09:51 PM, Bob Hinton wrote:
>>> Hello,
>>>
>>> We are trying to get Zenoss login authentication to use freeipa over
>>> LDAP. Group mappings don't currently work and we think this is because
>>> Zenoss requires the groupOfUniqueNames object class.
>>>
>>> I managed to add the object class to a test VM using
>>> vsphere_groupmod.ldif taken from
>>> http://www.freeipa.org/page/HowTo/vsphere5_integration -
>>>
>>> content of vsphere_groupmod.ldif -
>>>
>>> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
>>> changetype: modify
>>> add: schema-compat-entry-attribute
>>> schema-compat-entry-attribute: objectclass=groupOfUniqueNames
>>> -
>>> add: schema-compat-entry-attribute
>>> schema-compat-entry-attribute:
>>> uniqueMember=%mregsub("%{member}","^(.*)accounts(.*)","%1compat%2")
>>> -
>>>
>>> apply with -
>>>
>>> ldapmodify -x -D "cn=Directory Manager" -f vsphere_groupmod.ldif -W
>>>
>>> However, the following command seemed to freeze -
>>>
>>> ipa permission-mod "System: Read Group Compat Tree" --includedattrs
>>> uniquemember
>>>
>>> and I had to kill it then subsequent ldapsearch commands froze.
>> That's... strange. Looks like a DS bug.
> I tried this on one of the three live servers after using ipa-backup on
> each of them and it completed without hanging so this suggests a problem
> with my test VM rather than a bug.
> 
>>
>>> Rebooting the VM seemed to fix things and the groupOfUniqueNames object
>>> class appeared in the schema.
>>>
>>> I'd like to apply this to our live system which uses a master and two
>>> replicas running  IPA v4.2.0 on RHEL 7.2.
>>>
>>> Do I need to make the same change to all three servers ?
>> Changes in cn=config needs to be done on all servers as the tree is not
>> replicated. Normal permission changes are replicated (unless the permission 
>> is
>> about cn=config tree).
> Yes. I've now spotted that the change is confined to the single live
> server. I'll apply it to the other two when we've got the connectivity
> with Zenoss working.
>>> Can I leave the
>>> replicas connected or do I need to break the replication and
>>> re-establish it?
>> I do not see reason why you would need to break the replication between 
>> replicas.
>>
>>> Do I need the "ipa permission-mod" if so then how do I
>>> avoid it freezing ?
>> I think the freeze is a bug, I would try reproducing with the latest and
>> greatest 389-ds-base (I do not know what version you are using), the bug may 
>> be
>> already fixed (there were some bugs fixed).
> My test VM is quite old, since it didn't happen on the live server and
> that is more up to date, it suggests either a bug that has been fixed or
> a problem with the test VM.

Ok, thanks for info. It looks like you are in a "green state" then :-)

Martin

>>
>> And yes, the command is needed, so that the new attribute is allowed to be 
>> served.
>>
>> HTH,
>> Martin
>> .
>>
> Thanks
> 
> Bob
> 

-- 
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] Adding groupOfUniqueNames to all freeipa replicas for Zenoss LDAP authentication

[Martin Kosek]

On 05/25/2016 09:51 PM, Bob Hinton wrote:
> Hello,
> 
> We are trying to get Zenoss login authentication to use freeipa over
> LDAP. Group mappings don't currently work and we think this is because
> Zenoss requires the groupOfUniqueNames object class.
> 
> I managed to add the object class to a test VM using
> vsphere_groupmod.ldif taken from
> http://www.freeipa.org/page/HowTo/vsphere5_integration -
> 
> content of vsphere_groupmod.ldif -
> 
> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config
> changetype: modify
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute: objectclass=groupOfUniqueNames
> -
> add: schema-compat-entry-attribute
> schema-compat-entry-attribute:
> uniqueMember=%mregsub("%{member}","^(.*)accounts(.*)","%1compat%2")
> -
> 
> apply with -
> 
> ldapmodify -x -D "cn=Directory Manager" -f vsphere_groupmod.ldif -W
> 
> However, the following command seemed to freeze -
> 
> ipa permission-mod "System: Read Group Compat Tree" --includedattrs
> uniquemember
> 
> and I had to kill it then subsequent ldapsearch commands froze.

That's... strange. Looks like a DS bug.

> Rebooting the VM seemed to fix things and the groupOfUniqueNames object
> class appeared in the schema.
> 
> I'd like to apply this to our live system which uses a master and two
> replicas running  IPA v4.2.0 on RHEL 7.2.
> 
> Do I need to make the same change to all three servers ?

Changes in cn=config needs to be done on all servers as the tree is not
replicated. Normal permission changes are replicated (unless the permission is
about cn=config tree).

> Can I leave the
> replicas connected or do I need to break the replication and
> re-establish it?

I do not see reason why you would need to break the replication between 
replicas.

> Do I need the "ipa permission-mod" if so then how do I
> avoid it freezing ?

I think the freeze is a bug, I would try reproducing with the latest and
greatest 389-ds-base (I do not know what version you are using), the bug may be
already fixed (there were some bugs fixed).

And yes, the command is needed, so that the new attribute is allowed to be 
served.

HTH,
Martin

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

Re: [Freeipa-users] Error when adding new users via UI:

[Martin Kosek]

On 05/24/2016 04:07 PM, Rob Crittenden wrote:
> Traiano Welcome wrote:
>> Hi
>>
>> I have IPA server 4,2 running on centos 7
>> (ipa-server-4.2.0-15.el7.centos.3.x86_64).
>>
>> This morning, after many months of stable operation, I tried to add a
>> user and got this error via the web interface:
>>
>> ---
>> Operations error: Allocation of a new value for range cn=posix
>> ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config
>> failed! Unable to proceed.
>> ---
>>
>> So basically, can't add any new users.
>>
>> Would anyone know how I can troubleshoot this kind of IPA error, or
>> possibly have come across and resolved it before ?
> 
> At install a range of 100k id's is allocated to IPA. With each new master this
> range is divided in half. It appears you've exhausted one of the masters.
> 
> What you need to do is take an inventory of what ranges (if any) are allocated
> to various masters then you should be able to move things around (this is
> assuming of course that you haven't exhausted the entire range).
> 
> ipa-replica-manage list will give you a list of the IPA masters.
> 
> ipa-replica-manage dnarange-show  and ipa-replica-manage
> dnanextrange-show  will help discover what is available.
> 
> If you have things in nextrange then I'd start there with reallocation. 
> Setting
> a next range of 0-0 removes the next range (e.g. make it available for a
> primary range).
> 
> Take care when actually re-assigning ranges.
> 
> rob
> 

For the record, what currently did not work is when user is being added on a
master that does not have direct replication connect to other master with
available range.

This is improved from FreeIPA 4.3.1+:
https://fedorahosted.org/freeipa/ticket/4026

Martin

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

Re: [Freeipa-users] FreeIPA 4.3 with PWM 1.7 ?

[Martin Kosek]

On 05/23/2016 07:56 PM, Zak Wolfinger wrote:
> Does anyone have this combo working?  I’m running into problems with 
> pki-tomcat and tomcat for pwm conflicting and need some pointers.
> 
> Thanks!

You may need to do it on FreeIPA replica without a CA then or isolate these
somehow (containers?)

For the record, PWM question came here couple times already on this list, as
part of the discussion, we also recommended actually using some of the
alternatives we were building in FreeIPA:

https://www.redhat.com/archives/freeipa-users/2016-April/msg00205.html

Martin

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

Re: [Freeipa-users] What id my AD domain user password not available

[Martin Kosek]

On 05/23/2016 03:20 PM, Ben .T.George wrote:
> Hi
> 
> Thanks for your reply.
> 
> I saw this before but the thing is i cant able to follow up this one as i am 
> not 
> completely getting those steps
> 
> ipa trust-add --type=ad "ad_domain" --trust-secret
> 
> Is asking for key and what i need to gave ?
> 
> And the shown gif screens and current AD windows are different for me.

Hi,

Try checking the procedure in the guide:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/creating-trusts.html#create-trust-shared-secret
Maybe it will help you understand what needs to be clicked on AD side.

HTH,
Martin

> Regards
> Ben
> 
> On 23 May 2016 16:13, "Martin Babinsky"  > wrote:
> 
> On 05/23/2016 02:42 PM, Ben .T.George wrote:
> 
> Hi LIst,
> 
> my Windows domain Admin is not giving domain admin user password.
> 
> in this case how can i proceed ipa trust-add
> 
> regards,
> Ben
> 
> 
> 
> Hi Ben,
> 
> You can ask your AD domain admin to create a shared secret for 
> establishing
> trust. See the corresponding chapter in the guide for creating trusts[1] 
> for
> more details.
> 
> [1]
> 
> http://www.freeipa.org/page/Active_Directory_trust_setup#When_AD_administrator_credentials_aren.27t_available
> 
> 
> -- 
> 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

Re: [Freeipa-users] authconfig vs ipa-client-install

[Martin Kosek]

On 05/19/2016 04:12 PM, lejeczek wrote:
> hi evebody
> 
> I'd like to ask how does, what ipa installation does ot a box, relate to
> authconfig?
> 
> I am specifically thinking of the fact that authconfig does not indicate that
> IPAv2 is used, on a box which is IPA member/client.
> 
> Is it because it is for some older IPA, that "v2"? If yes, then should 
> authconf
> not reflect somehow that IPA is configured and used?

The IPAv2 related options in authconfig are rather outdated and will be removed
in future (we are having all sort of discussions what to do with authconfig).

Please simply use ipa-client-install if you are joining IPA. If you are joining
AD, use realmd. If you are connecting to some other Identity system, you can
use authconfig (and probably just enable SSSD) or edit PAM in the worst case.

There is some information in this doc:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_Authentication.html#configuring-auth-with-idm

HTH,
Martin

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

Re: [Freeipa-users] Changing spec.page_length?

[Martin Kosek]

On 05/17/2016 01:54 AM, Jeffery Harrell wrote:
> Is there a “soft” way to change the number of rows in tables like the hosts 
> and 
> DNS records search facets? I think I’d happily trade a little interactivity 
> when 
> going from one facet to another for the ability to see four or five times as 
> much information on a single screen at once. I get that I can write a 
> JavaScript 
> mod that pokes into the individual tables and modifies spec.page_length, but 
> is 
> there an easier way? A setting somewhere maybe? The source code suggests the 
> answer is no but I figured it couldn’t hurt to ask.

There is no such nice way in FreeIPA currently (as you have found out). The
best you can do now is writing a UI plugin (as you have also found out).

But you can sign to the respective RFE and watch the progress or even provide
patches if you are JavaScript savvy:

https://fedorahosted.org/freeipa/ticket/5742

Martin

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

Re: [Freeipa-users] FreeIPA DNS Module (named.conf)

[Martin Kosek]

On 05/16/2016 02:03 PM, Günther J. Niederwimmer wrote:
> Hello,
> 
> I have a question about the named.conf, is it possible to change the 
> named.conf, to mace ACL or views, or is named.conf overwritten from freeipa-
> module ?
> 

Hello,

FreeIPA indeed replaces default named.conf during installation and then later
extends it when updates are needed. So it may not be too safe adding your own
changes there and turning it into shared DNS with FreeIPA (though it should
work if done after installation, Petr Spacek will know better).

As for DNS Views, see
https://fedorahosted.org/freeipa/ticket/2802
for information.

Thanks,
Martin

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

Re: [Freeipa-users] otp question to limit brute force vector for web applications

[Martin Kosek]

On 05/13/2016 05:24 PM, Thomas Heil wrote:
> Hi,
> 
> On 13.05.2016 16:12, Petr Spacek wrote:
>> On 13.5.2016 15:25, Thomas Heil wrote:
>>> Hi,
>>>
>>> I would like to reduce the vector of brute force attacks in my web
>>> application written in php. Users can login via passord and otp which
>>> are hosted on freeipa.
>>>
>>> To achieve this I would like to check the otp first, so no password auth
>>> is done on the freeipa server and no user can be locked out.
>>>
>>> If the otp is correct, the user is now allowed to to login via password+otp.
>>>
>>> unfortunately, there is no api method that can check only the otp for a
>>> user with an  identity.
>>>
>>> Would it be possible to expose such a new method?
>>
>> This would open a new attack vector so it is a bad idea.
>>
>> Attacker must not be able to distinguish case where password OR OTP is
>> correct/wrong. If you allow this, the attacker will be able to crack OTP 
>> first
>> and then continue with password, so you are making it easier.
> 
> Okay you are right with that. Sorry.
> 
> My intention is to avoid to be vulnerable for brute force attacks. I
> have a trust with an active directory and want to avoid that the user on
> ad side is locked if otp is wrong.
> 
> Is this possible?

Not at the moment. We have an RFE filed, but we cannot augment AD user
authentication with OTP yet:

https://fedorahosted.org/freeipa/ticket/4876

Martin

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

Re: [Freeipa-users] AD Primary Groups are ignored in FreeIPA?

[Martin Kosek]

On 05/16/2016 05:28 AM, Lachlan Musicman wrote:
> Hola,
> 
> We have an interesting scenario that is hard to find any information on.
> 
> Due to permission restrictions, a NAS that is mounted and visible by both AD 
> and 
> 'nix clients, every user belongs to a particular primary group.
> 
> When we try doing idoverride's on the groups, it fails with the Primary 
> Group. 
> In some cases, the primary group doesn't even appear in a getent or id 
> request. 
> Sometimes it appears with incorrect name or GID.
> 
> We have found it hard to get repeatable "failures", but here are two:
> 
> 1. getent group  (where groupname is any group, but is a primary 
> group for a subset of members)
> 
>   - does not return any member that has groupname as a primary group in AD.
> 
> 2. Overriding a group
> 
> if the user has that group as a primary group (in AD), it will override the 
> name, but not the GID.
> else, the override works.
> 
> There were a number of other unusual results that are hard to explain how to 
> reproduce because it was all so seemingly random.
> 
> 
> I feel like it would be an obvious need - to translate or override AD primary 
> groups to FreeIPA groups, but this doesn't seem possible.
> 
> Have we set IPA  up incorrectly, or are we hitting on something else?
> 
> I found this AD support problem for Win2003, but I feel like it's old and 
> would 
> surely have been solved? https://support.microsoft.com/en-us/kb/275523
> 
> Also, their solution ("hack AD, then hack your other LDAP software") is, for 
> some reason, funny to me.
> 
> Cheers
> L.

Hello Lachlan,

It seems you are looking for this extension:
https://fedorahosted.org/sssd/ticket/1872

It is not done yet, there is a plenty of information in the ticket comments.
Please let us know if this does not help.

Martin

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

Re: [Freeipa-users] DNSSEC NSEC3 Parameter

[Martin Kosek]

On 05/14/2016 07:49 PM, Günther J. Niederwimmer wrote:
> Hello,
> 
> Thanks for answer,
> 
> Am Freitag, 13. Mai 2016, 09:40:05 CEST schrieb Martin Kosek:
>> On 05/12/2016 04:41 PM, Günther J. Niederwimmer wrote:
>>> Hello,
>>> I have the Problem to find the correct way for NSEC3PARAM ?
>>>
>>> With your Help I have this found
>>>
>>> ipa dnszone-mod example.com. --nsec3param-rec " 
>>>  "
>>>
>>> But it dos not work correct ?
>>>
>>> Now the question, is this the correct way
>>>
>>> ipa dnszone-mod example.com. --nsec3param-rec "1 7 100 f9ba6264232b7283"
>>>
>>> to insert the NSEC3PARAMETER ??
>>
>> This should be right, there were related fixes by
>> https://fedorahosted.org/freeipa/ticket/4413
>>
>> Your second command works in my test environment:
>> # ipa dnszone-mod example.com. --nsec3param-rec "1 7 100 f9ba6264232b7283"
>> # dig -t nsec3param example.com. +short
>> 1 7 100 F9BA6264232B7283
> 
> The question is now, I mean the  Parameter is wrong ?
> 
> I make a test without Freeipa on a "normal" DNS (DNSSEC) installation (bind 9)
> 
> dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N 
> INCREMENT -o $ZONE -t $ZONEDIR/$ZONEFILE
> 
> and a
> 
> dig -t nsec3param example.com. +short 
> 
> the relult is
> 
> 1 0 10 
> 
> 1 is sha1 
> so I mean (?) "0" is the correct parameter ?.
> "10" is the default for Bind
> 
> so I hope this is working now correct 
> 
> Thanks for testing and answer

Ahh, now I understand what you were asking about. The validators we have in DNS
records are only limited, mostly to check that you are entering the right
number of fields or that the data type is OK. They usually do not do any more
complex evaluation. I would let Petr Spacek say if we need to change anything
in FreeIPA in this case.

Martin

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

Re: [Freeipa-users] DNSSEC NSEC3 Parameter

[Martin Kosek]

On 05/12/2016 04:41 PM, Günther J. Niederwimmer wrote:
> Hello,
> I have the Problem to find the correct way for NSEC3PARAM ?
> 
> With your Help I have this found
> 
> ipa dnszone-mod example.com. --nsec3param-rec "  
>  "
> 
> But it dos not work correct ?
> 
> Now the question, is this the correct way
> 
> ipa dnszone-mod example.com. --nsec3param-rec "1 7 100 f9ba6264232b7283"
>  
> to insert the NSEC3PARAMETER ??

This should be right, there were related fixes by
https://fedorahosted.org/freeipa/ticket/4413

Your second command works in my test environment:
# ipa dnszone-mod example.com. --nsec3param-rec "1 7 100 f9ba6264232b7283"
# dig -t nsec3param example.com. +short
1 7 100 F9BA6264232B7283

Martin

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

Re: [Freeipa-users] Exposing LDAP attributes with hyphens in their names?

[Martin Kosek]

On 05/06/2016 07:12 PM, Jeffery Harrell wrote:
> Hi. I’m very new to IPA; I only picked it up a couple weeks ago. So this may 
> be 
> a remedial question.
> 
> I’d like to expose, both via the CLI and the GUI, certain LDAP attributes 
> which 
> have hyphens in their names — e.g., "apple-user-homeurl.” The Param class 
> rejects these attributes because of the hyphens; the name of the Param 
> doesn’t 
> conform to the regular expression so an exception gets thrown. This code does 
> not work:
> 
> |user.user.takes_params = user.user.takes_params + ( Str( 
> 'apple-user-homeurl?', 
> cli_name='appleuserhomeurl', label=_('Apple User Home URL'), doc=_('Apple 
> user 
> home URL.'), ), ) |
> 
> Is there a sensible way of getting around that, or will I have to subclass 
> Param 
> and write a whole bunch of new code to get this to work?
> 
> Thanks very much.
> 
> Jeffery

Did you check the documentation we have so far?

http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf
http://abbra.fedorapeople.org/guide.html

CCing Jan for reference.

Martin

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

Re: [Freeipa-users] Automatic consistency checking

[Martin Kosek]

On 05/05/2016 04:35 PM, Martin Basti wrote:
> 
> 
> On 05.05.2016 15:54, Andrew Holway wrote:
> 
> Hello,
> 
> We've been using Freeipa on Centos for a while and found one day that the
> replication stuff was broken and that the LDAP database on our pair of IPA
> servers was inconsistent. We didn't know how long this had been broken for
> but we were not able to repair it either.
> 
> We use AWS so we've now deployed RHEL AMI's and are now using IdM so we 
> can
> get support when this is breaking but I am a bit stuck how to monitor that
> the replication is still working.
> 
> So is there some monitoring mechanisms in FreeIPA?
> 
> Cheers,
> 
> Andrew
> 
> 
> 
> This is planned for future, you can use 

Right.  This is the long term plan and design:
http://www.freeipa.org/page/V4/Monitor_Replication_Topology

Ludwig (CCed) had some ideas already, I am not sure if all of them are in the
design.

> https://github.com/peterpakos/ipa_check_consistency (community script without 
> any guarantee) to check your servers.


-- 
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] Looking for documentation for Python API

[Martin Kosek]

On 05/07/2016 09:07 AM, Joshua J. Kugler wrote:
> On Friday, May 06, 2016 09:04:59 Martin Basti wrote:
>> since IPA4.2 web UI contains API browser (IPA Server/API Browser)
>>
>> So for example for caacl-add:
>> api.Command.caacl_add(u'argument-ca-acl-name', description=u"optional
>> description")
>>
>> you can try commands in "ipa console" it contains initialized API, just
>> call api.Command.()
>>
>> API.txt provides the same information as API browser, but browser looks
>> better :)
>>
>> Feel free to ask anything, if you identified gaps in docs which are hard
>> to understand for non-IPA developer feel free report it, or feel free to
>> create howTo in freeipa.org page.
> 
> Thanks for the pointers. I'm looking at automating some user and group 
> additions, group editing, etc.  Am I right in assuming that anything that 
> uses 
> the api.Command. will require a kinit  before it is run, 
> even if it is via the Python API? If I want to use a user/pass from the 
> script 
> itself (and not have a shell script which does kinit, then fires off my 
> Python 
> script) would I be better off hitting the web API with sessions and JSON-RPC 
> as 
> detailed here:
> 
> https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/
> 
> Put another way, since I want to hit the API from a system that might not 
> have 
> sssd installed, nor has joined the realm, I assume it would be *impossible* 
> to 
> use api.Command. as it relies on a Kerberos ticket?  To put it yet 
> another way: is there a way to hand a user/pass to the Python API and 
> authenticate that way.

The API itself can be hit with user/password, as noted in Alexander's blog. If
you want to use the actual Python API, Kerberos may be the only way. But I
think Jan or Petr may had some other (hacky) way to pass user+password there 
too.

> Those are the questions I did not see addressed in the docs that I found.  
> There were lots of examples of invoking commands, but I never saw anything 
> about authenticating to the server before running the commands.
> 
> Thanks again for the pointers, and if there is documentation I missed, feel 
> free to point me in that direction.

-- 
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] Get Creation Time / Last Login Time for Users

[Martin Kosek]

On 05/05/2016 03:23 AM, Jeff Hallyburton wrote:
> Hello,
> 
> We're looking for a way to get last login time and creation time for
> users configured in FreeIPA.  This information doesn't seem to be in
> the WebUI and ipa user-status only provides limited information (last
> failed/successful logins in seconds since epoch).  Is there a
> supported way to get this information?
> 
> Jeff Hallyburton
> Strategic Systems Engineer
> Bloomip Inc.
> Web: http://www.bloomip.com
> 
> Engineering Support: supp...@bloomip.com
> Billing Support: bill...@bloomip.com
> Customer Support Portal:  https://my.bloomip.com
> 

Hi,

Could you use ldapsearch?

# ldapsearch -Y GSSAPI -b "cn=users,cn=accounts,dc=rhel72" createtimestamp
krbLastSuccessfulAuth
...
# admin, users, accounts, rhel72
dn: uid=admin,cn=users,cn=accounts,dc=rhel72
createtimestamp: 20160308160512Z
krbLastSuccessfulAuth: 20160511084800Z

# labadmin, users, accounts, rhel72
dn: uid=labadmin,cn=users,cn=accounts,dc=rhel72
createtimestamp: 20160321081650Z
krbLastSuccessfulAuth: 20160321082135Z
...

Martin

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

Re: [Freeipa-users] sudorule

[Martin Kosek]

On 05/04/2016 03:41 PM, Armstrong, Jeffrey wrote:
> Hi
> 
> I’m trying to add a to add a sudo command to a sudo rule.  It’s executing the 
> command but it’s not adding the sudo command.
> 
> ipa sudorule-add-allow-command  –sudocmds  "/bin/su "  bkrc_rule
> 
>Rule name: bkrc_rule
> 
>Enabled: TRUE
> 
> -
> 
> Number of members added 0
> 
> Thanks
> 
> Jeff Armstrong


Does the SUDO command object exists?

# ipa sudorule-add-allow-command  --sudocmds  "/bin/su" test
  Rule name: test
  Enabled: TRUE
-
Number of members added 0
-
# ipa sudocmd-show /bin/su
ipa: ERROR: /bin/su: sudo command not found

More info here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/adding-sudo.html

I assume not. I actually think that this is a bug that FreeIPA does not display
any warning in this ticket. Can you please file a ticket/bug?

https://fedorahosted.org/freeipa/newticket

Thanks,
Martin

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

Re: [Freeipa-users] Who uses FreeIPA?

[Martin Kosek]

On 05/04/2016 09:23 AM, Jakub Hrozek wrote:
> On Tue, May 03, 2016 at 11:31:02PM +0200, Lukas Slebodnik wrote:
>> On (03/05/16 15:09), Alexandre de Verteuil wrote:
>>> Hello all,
>>>
>>> I've deployed FreeIPA in my home lab and I'm happy to have single
>>> sign-on for all my Archlinux virtual machines and Fedora laptops :)
>>>
>>> It took me lots of research and conversations before hearing about
>>> FreeIPA for the first time while searching for a libre SSO solution. I
>>> think FreeIPA needs much more exposure. I am really impressed with it.
>>> Tomorrow I am giving a short presentation at my workplace to talk about
>>> it and invite other sysadmins to try it.
>>>
>>> I would like to make a slide showing the current adoption of FreeIPA. I
>>> read that Red Hat uses it internally, but do they actually deploy it in
>>> their client's infrastructures? Are there any big companies that use it?
>>> Even if I only have reports of schools and small businesses would be
>>> good enough to say it's production ready and it has traction.
>>>
>>> Whether you are reporting about your own use or you know where I can
>>> find out more would be greatly appreciated! I have not found a "Who uses
>>> FreeIPA" page on the Internet.
>>>
>> The GNOME Infrastructure is now powered by FreeIPA!
>> October 7, 2014
>>
>> https://www.dragonsreach.it/2014/10/07/the-gnome-infrastructure-is-now-powered-by-freeipa/
> 
> Would it make sense to add 'success stories' like this to the
> freeipa.org home page? Of course, we can't use Red Hat IDM customers,
> but those that use freeipa on Fedora/CentOS and hopefully soon on Ubuntu
> could be added there if they would agree..

I think it would make sense. We already know at least about GNOME as Lukas
mentioned or about eBay's Hadoop clusters:

https://hadoopsummit.uservoice.com/forums/344958-governance-and-security/suggestions/11664876-freeipa-for-securing-hadoop-fish

I think we should start a new "References" page on the FreeIPA.org wiki and ask
for success stories from this list. Any takers? :-)

-- 
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] Inplace upgrade

[Martin Kosek]

On 05/04/2016 01:31 PM, barry...@gmail.com wrote:
> U meant it fail  start if update minor version only?
> 
> 2016年5月4日 下午7:25 於 "Lukas Slebodnik"  > 寫道：
> 
> On (04/05/16 13:17), barry...@gmail.com  wrote:
>  >Can speicific ninor version?
> Yes you can
> 
> yum update ipa-server-3.0.0-37.el6.x86_64
> 
> However, it can fail if this version is not available in repositories.
> 
> BTW the latest version in el6 is 3.0.0-47.el6
> 
> LS

I believe all the info should be on this page:
http://www.freeipa.org/page/Upgrade

If not, we should improve it - suggestions welcome!

Thanks,
Martin

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

Re: [Freeipa-users] freeipa password policy ( hsitory ) getting reset with password reset

[Martin Kosek]

On 05/03/2016 08:20 AM, Rakesh Rajasekharan wrote:
> Hi,
> 
> I am running a freeipa server 4.2.x.
> 
> I have the following password global password policy set to force a history 
> of 3
> 
> ipa pwpolicy-mod global_policy --history=3 --maxlife=90 --minlength=8 
> --maxfail=3 --failinterval=300
> 
> 
> This works good when the user himself changes the password.. and IPA does not 
> allow reusing older password.
> 
> However, if the admin resets it "ipa user-mod testuser --random" then it 
> seems 
> to reset the password history as well and the user can now re-use his older 
> password
> 
> Is this expected or is there something I can do about it.

Good question, CCing Simo on this one.

> Also, is there a way to get the password expiry warning at the terminal when 
> a 
> user logs in , something similar to the "pwdExpireWarning" in ldap.
> 
> I searched a bit and could only find setting up email alerts .

CCing Jakub from SSSD team.

Martin

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

Re: [Freeipa-users] ipa trust-fetch-domains failing.

[Martin Kosek]

Thanks for confirmation. Can you share with the list what was the root cause of
your problem? Maybe it helps someone else.

Thanks,
Martin

On 04/30/2016 08:23 AM, Ben .T.George wrote:
> HI All
> 
> this issue has solved
> 
> On Sat, Apr 30, 2016 at 9:16 AM, Ben .T.George  > wrote:
> 
> when i am running ipa trust-fetch-domains "kwttestdc.com.kw
> " , i am getting below error in error_log
> 
> [Sat Apr 30 09:14:25.107449 2016] [:error] [pid 2666] ipa: ERROR: Failed 
> to
> call com.redhat.idm.trust.fetch_domains helper.DBus exception is
> org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible 
> causes
> include: the remote application did not send a reply, the message bus
> security policy blocked the reply, the reply timeout expired, or the 
> network
> connection was broken..
> [Sat Apr 30 09:14:25.108353 2016] [:error] [pid 2666] ipa: INFO:
> [jsonserver_session] admin@IDM.LOCAL: 
> trust_fetch_domains(u'kwttestdc.com.kw
> ', rights=False, all=False, raw=False,
> version=u'2.156'): ServerCommandError
> 
> On Sat, Apr 30, 2016 at 12:00 AM, Ben .T.George  > wrote:
> 
> Hi
> 
> Anyone please help me to fix this issue.
> 
> i have created new group in AD( 4 hours back) and while i was mapping
> this group as --external, i am getting below error.
> 
> 
> /[root@freeipa sysctl.d]# ipa group-add --external ad_admins_external
> --desc "KWTTESTDC.com.KW  AD
> Administrators-External"/
> /--/
> /Added group "ad_admins_external"/
> /--/
> /  Group name: ad_admins_external/
> /  Description: KWTTESTDC.com.KW  AD
> Administrators-External/
> /[root@freeipa sysctl.d]# ipa group-add-member ad_admins_external
> --external "KWTTESTDC\test admins"/
> /[member user]:/
> /[member group]:/
> /  Group name: ad_admins_external/
> /  Description: KWTTESTDC.com.KW  AD
> Administrators-External/
> /  Failed members:/
> /member user:/
> /member group: KWTTESTDC\test admins: Cannot find specified domain
> or server name/
> /-/
> /Number of members added 0/
> -
> 
> 
> 
> On Fri, Apr 29, 2016 at 4:41 PM, Ben .T.George  > wrote:
> 
> Hi
> 
> while issuing ipa trust-fetch-domains, i am getting below error.
> 
> i have created new security group in AD and i want to add this to
> external group.
> 
> [root@freeipa ~]# ipa trust-fetch-domains "kwttestdc.com.kw
> "
> ipa: ERROR: error on server 'freeipa.idm.local': Fetching domains
> from trusted fo   
>  
>   rest failed. See details in the error_log
> 
> help me to fi/expalin more about this error
> 
> Regards
> 
> 
> 
> 
> 
> 

-- 
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] Free IPA Client in Docker

[Martin Kosek]

On 04/28/2016 08:14 PM, Hosakote Nagesh, Pawan wrote:
> Hi,
>   I am planning to deploy FreeIPA Client in a docker where my Apps are
> running. However I hit a road block as there seems to be problem with the
> docker’s hostname settings
> In DNS records.  

CCing Jan on this one. Did you try to use SSSD Docker container we already have
instead?

https://hub.docker.com/r/fedora/sssd/
https://www.adelton.com/docs/docker/fedora-sssd-container

Martin

> Debug Log
> ———
> 
> ipa-client-install --hostname=`hostname -f` --mkhomedir -N --force-join 
> —debug 
> 
> .
> 
> .
> 
> .
> 
> .
> 
> debug
> 
> zone phx01.eaz.ebayc3.com.
> 
> update delete . IN A
> 
> show
> 
> send
> 
> update add . 1200 IN A 172.17.0.3
> 
> show
> 
> send
> 
> 
> Starting external process
> 
> args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt
> 
> Process execution failed
> 
> Traceback (most recent call last):
> 
>   File "/usr/sbin/ipa-client-install", line 2603, in 
> 
> sys.exit(main())
> 
>   File "/usr/sbin/ipa-client-install", line 2584, in main
> 
> rval = install(options, env, fstore, statestore)
> 
>   File "/usr/sbin/ipa-client-install", line 2387, in install
> 
> client_dns(cli_server[0], hostname, options.dns_updates)
> 
>   File "/usr/sbin/ipa-client-install", line 1423, in client_dns
> 
> update_dns(server, hostname)
> 
>   File "/usr/sbin/ipa-client-install", line 1410, in update_dns
> 
> if do_nsupdate(update_txt):
> 
>   File "/usr/sbin/ipa-client-install", line 1346, in do_nsupdate
> 
> ipautil.run(['/usr/bin/nsupdate', '-g', UPDATE_FILE])
> 
>   File "/usr/lib/python2.7/dist-packages/ipapython/ipautil.py", line 303, in 
> run
> 
> close_fds=True, env=env, cwd=cwd)
> 
>   File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> 
> errread, errwrite)
> 
>   File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
> 
> raise child_exception
> 
> OSError: [Errno 2] No such file or directory
> 
> 
> 
> As a Follow up question I also wanted to know why is absolutely necessary for
> Kerberos Client to have hostname? Wont Client initiate the connection and
> FreeIPA server can take it from there.
> If so what is the need of FQDN for FreeIPA client at all?
> 
> -
> Best,
> Pawan
> 
> 

-- 
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 vulnerability management SSL

[Martin Kosek]

On 04/28/2016 01:23 AM, Sean Hogan wrote:
> Hi Martin,
> 
> No joy on placing - in front of the RC4s
> 
> 
> I modified my nss.conf to now read
> # SSL 3 ciphers. SSL 2 is disabled by default.
> NSSCipherSuite 
> +aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_sha
> 
> # SSL Protocol:
> # Cryptographic protocols that provide communication security.
> # NSS handles the specified protocols as "ranges", and automatically
> # negotiates the use of the strongest protocol for a connection starting
> # with the maximum specified protocol and downgrading as necessary to the
> # minimum specified protocol that can be used between two processes.
> # Since all protocol ranges are completely inclusive, and no protocol in the
> NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
> 
> dse.ldif
> 
> dn: cn=encryption,cn=config
> objectClass: top
> objectClass: nsEncryptionConfig
> cn: encryption
> nsSSLSessionTimeout: 0
> nsSSLClientAuth: allowed
> nsSSL2: off
> nsSSL3: off
> creatorsName: cn=server,cn=plugins,cn=config
> modifiersName: cn=directory manager
> createTimestamp: 20150420131850Z
> modifyTimestamp: 20150420131906Z
> nsSSL3Ciphers: +all,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4
> _56_sha,-tls_dhe_dss_1024_rc4_sha
> numSubordinates: 1
> 
> 
> 
> But I still get this with nmap.. I thought the above would remove 
> -tls_rsa_export1024_with_rc4_56_sha but still showing. Is it the fact that I 
> am not
> offering -tls_rsa_export1024_with_rc4_56_sha? If so.. not really 
> understanding 
> where it is coming from cept the +all from DS but the - should be negating 
> that?
> 
> Starting Nmap 5.51 ( http://nmap.org  ) at 2016-04-27 17:37 
> EDT
> Nmap scan report for rtpvxl0077.watson.local (10.110.76.242)
> Host is up (0.86s latency).
> PORT STATE SERVICE
> 636/tcp open ldapssl
> | ssl-enum-ciphers:
> | TLSv1.2
> | Ciphers (13)
> | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
> | SSL_RSA_FIPS_WITH_DES_CBC_SHA
> | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
> | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
> | TLS_RSA_WITH_3DES_EDE_CBC_SHA
> | TLS_RSA_WITH_AES_128_CBC_SHA
> | TLS_RSA_WITH_AES_128_CBC_SHA256
> | TLS_RSA_WITH_AES_128_GCM_SHA256
> | TLS_RSA_WITH_AES_256_CBC_SHA
> | TLS_RSA_WITH_AES_256_CBC_SHA256
> | TLS_RSA_WITH_DES_CBC_SHA
> | TLS_RSA_WITH_RC4_128_MD5
> | TLS_RSA_WITH_RC4_128_SHA
> | Compressors (1)
> |_ uncompressed
> 
> Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
> 
> 
> 
> It seems no matter what config I put into nss.conf or dse.ldif nothing 
> changes 
> with my nmap results. Is there supposed to be a be a section to add TLS 
> ciphers 
> instead of SSL

Not sure now, CCing Ludwig who was involved in the original RHEL-6
implementation. Just to be sure, when you are modifying dse.ldif, the procedure
should be always following:

1) Stop Directory Server service
2) Modify dse.ldif
3) Start Directory Server service

Otherwise it won't get applied and will get overwritten later.

In any case, the ciphers with RHEL-6 should be secure enough, the ones in
FreeIPA 4.3.1 should be even better. This is for example an nmap taken on
FreeIPA Demo instance that runs on FreeIPA 4.3.1:

$ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org

Starting Nmap 7.12 ( https://nmap.org ) at 2016-04-28 12:02 CEST
Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99)
Host is up (0.18s latency).
PORTSTATE SERVICE
636/tcp open  ldapssl
| ssl-enum-ciphers:
|   TLSv1.2:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|   TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 21.12 seconds

Martin

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

Re: [Freeipa-users] IPA vulnerability management SSL

[Martin Kosek]

On 04/27/2016 07:27 AM, Sean Hogan wrote:
> Hello,
> 
> We currently have 7 ipa servers in multi master running:
> 
> ipa-server-3.0.0-47.el6_7.1.x86_64
> 389-ds-base-1.2.11.15-68.el6_7.x86_64
> 
> Tenable is showing the use of weak ciphers along with freak vulnerabilities. 
> I 
> have followed
> https://access.redhat.com/solutions/675183 however issues remain in the 
> ciphers 
> being used.

Can you show the full report, so that we can see what's wrong? What I am
looking for also is if the problem is LDAPS port or HTTPS port, so that we are
not fixing wrong service.

DS ciphers were hardened in RHEL-6.x and RHEL-7.x already as part of this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1154687

Further hardening comes with FreeIPA 4.3.1+:
https://fedorahosted.org/freeipa/ticket/5684
https://fedorahosted.org/freeipa/ticket/5589

(it should appear in RHEL-7.3+)

Martin

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

Re: [Freeipa-users] IPA & Yubikey

[Martin Kosek]

On 04/22/2016 10:40 PM, Jeremy Utley wrote:
> Hello all!
> 
> I'm quite close to reaching the ideal point with our new FreeIPA setup, but 
> one 
> thing that is standing in the way is 2FA.  I know FreeIPA has support for 
> Google 
> Auth, FreeOTP, and Yubikey.  We'd like to go with Yubikeys over the 
> phone-based 
> systems, but a lot of the docs regarding Yubikey seem to either be out-dated, 
> or 
> not real clear (at least to me).  So I'd like to ask a few questions to make 
> sure I'm understanding correctly.
> 
> 1) It looks like the normal setup of a Yubikey is to plug it into a machine 
> and 
> run the "ipa otptoken-add-yubikey" command.  This implies that the machine 
> that 
> sets up the Yubikey needs to be part of the FreeIPA domain, which presents 
> somewhat of a problem for us, as our current IPA setup has no desktops, and 
> is 
> in a remote "lights-out" datacenter an hour's drive from our office.  I did 
> see 
> a post recently in the archives of someone figuring out how to set up a 
> Yubikey 
> via the web interface 
> (https://www.redhat.com/archives/freeipa-users/2016-March/msg00114.html) - 
> would 
> this be viable?

Interesting question/suggestion, CCing Nathaniel on this one, he authored the
feature.

> 2) Does the otptoken-add-yubikey command actually change the programming of 
> the 
> Yubikey, or does it simply read it's configuration?  We have some users who 
> are 
> already using a Yubikey for personal stuff, and we'd like to allow those 
> users 
> to continue to use their existing Yubikey to auth to our IPA domain, but if 
> the 
> add command changes the programming of the key, that may not be possible 
> without 
> using the second slot, and if users are already using the second slot, they 
> are 
> out of luck.
> 
> 3) Does Yubikey auth require talking to the outside world to function?  Our 
> IPA 
> setup is within a secure zone, with no direct connectivity to the outside 
> world, 
> so if this is necessary, it would be a possible deal-breaker for these.

None of the FreeIPA setup should require communication with the outside world,
maybe except some of the current DNS checks during validation. If it does, it
sounds as a bug to me, as I know about multiple deployments of FreeIPA in such
environments.

Martin

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

Re: [Freeipa-users] Let's Encrypt SSL pkscs 12 problem notes anyone. CENTOS 7 FreeIPA install

[Martin Kosek]

On 04/21/2016 11:22 AM, Branko Quenode wrote:
> Hi ,
> 
> I am trying to install freeipa with centos and Let's Encrypt SSL.
> 
> I create lets-encrypt with webroot option.
> 
> Then i did
> 
> cat privkey.pem fullchain.pem > /root/key.pem
> 
> openssl pkcs12 -export -in /root/key.pem  -out ipa.pkcs12 -name 
> "ipa.somedomain.com "
> 
> 
> ipa-server-install --ip-address= 
>   --http_pkcs12=/etc/letsencrypt/live/ipa.somedomein.com/ipa.pkcs12 
>  
> --dirsrv_pkcs12=/etc/letsencrypt/live/ipa.somedomain.com/ipa.pkcs12 
>  
> --root-ca-file=/etc/letsencrypt/live/ipa.somedomain.com/fullchain.pem 
> 
> 
> I got error
> ipa.ipapython.install.cli.install_tool(Server): ERRORThe full certificate 
> chain is not present in /etc/letsencrypt/live/ipa.somedomain.com/ipa.pkcs12 
> 
> 
> 
> What I am missing intermediate.crt maybe ?

Probably. Sounds like

https://www.redhat.com/archives/freeipa-users/2016-April/msg00161.html

Martin

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

Re: [Freeipa-users] FreeIPA and PWM

[Martin Kosek]

On 04/20/2016 05:23 PM, Tiemen Ruiten wrote:
> Hello,
> 
> I'm trying to set up a self-service page for a new IPA domain and I'm trying 
> to 
> use PWM for that.
> 
> When I try to bind to FreeIPA from within PWM, with the configured "LDAP 
> Proxy 
> User", I get the following error:
> 
> error connecting to ldap server 'ldaps://polonium.ipa.rdmedia.com:636 
> ': unable to create connection: unable 
> to 
> bind to ldaps://polonium.ipa.rdmedia.com:636 
>  as 
> cn=svcpwmproxy,cn=groups,cn=accounts,dc=ipa,dc=rdmedia,dc=com reason: [LDAP: 
> error code 48 - Inappropriate Authentication]
> 
> In /var/log/krb5kdc.log I see:
> 
> Apr 20 17:12:29 polonium.ipa.rdmedia.com  
> krb5kdc[25760](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.50.33 
> : NEEDED_PREAUTH: 
> host/protactinium.ipa.rdmedia@ipa.rdmedia.com 
>  for 
> krbtgt/ipa.rdmedia@ipa.rdmedia.com 
> , 
> Additional pre-authentication required
> Apr 20 17:12:29 polonium.ipa.rdmedia.com  
> krb5kdc[25760](info): closing down fd 12
> Apr 20 17:12:29 polonium.ipa.rdmedia.com  
> krb5kdc[25760](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.50.33 
> : ISSUE: authtime 1461165149, etypes {rep=18 tkt=18 
> ses=18}, host/protactinium.ipa.rdmedia@ipa.rdmedia.com 
>  for 
> krbtgt/ipa.rdmedia@ipa.rdmedia.com 
> 
> Apr 20 17:12:29 polonium.ipa.rdmedia.com  
> krb5kdc[25760](info): closing down fd 12
> Apr 20 17:12:29 polonium.ipa.rdmedia.com  
> krb5kdc[25760](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.50.33 
> : ISSUE: authtime 1461165149, etypes {rep=18 tkt=18 
> ses=18}, host/protactinium.ipa.rdmedia@ipa.rdmedia.com 
>  for 
> ldap/polonium.ipa.rdmedia@ipa.rdmedia.com 
> 
> Apr 20 17:12:29 polonium.ipa.rdmedia.com  
> krb5kdc[25760](info): closing down fd 12
> 
> What is going on? What can I do to debug this more?
> 
> 
> -- 
> Tiemen Ruiten
> Systems Engineer
> R&D Media

Hello Tiemen,

Just for the record, in FreeIPA we have been also working on our own version of
the Community Portal that could be useful for the registration and is already
well integrated with FreeIPA:

https://github.com/freeipa/freeipa-community-portal
http://freeipa-community-portal.readthedocs.org/en/latest/

CCing Christian who currently owns the project.

HTH,
Martin

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

Re: [Freeipa-users] howto ldapsearch for disabled/enabled users?

[Martin Kosek]

On 04/15/2016 04:06 PM, Harald Dunkel wrote:
> Hi David,
> 
> On 04/15/16 15:11, David Kupka wrote:
>>
>> Hello Harri,
>>
>> the attribute you're looking for is 'nsaccountlock'. This command should 
>> give you uids of all disabled users:
>>
>> $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=test 
>> "(nsaccountlock=TRUE)" uid
>>
> 
> Thats exactly what I was looking for. For the record: Searching for
> "nsaccountlock=FALSE" did not work. I had to use
> 
> ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=test 
> '(!(nsaccountlock=TRUE))' uid
> 
> instead.

Right, this is because nsaccountlock is not with a user by default, it will be
there after the first time the user is administratively disabled and then 
enabled.

-- 
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 set passwords which never expire ?

[Martin Kosek]

On 04/12/2016 02:10 PM, dbisc...@hrz.uni-kassel.de wrote:
> Hi,
> 
> On Tue, 12 Apr 2016, bahan w wrote:
> 
>> I am using FreeIPA 3.0 and I would like, for specific accounts, to set
>> passwords unexpirables.
>>
>> I tried to set a pwpolicy for this with the option maxage set to 0, but it
>> did not help and the maxage was 0 (password already expired).
>>
>> Is there a way, with this Ipa version, to set passwords unexpirables ?
> 
> it is possible to create a password policy (tab "Policy" in the web interface)
> for a user group of your choice and change the password max lifetime to (e.g.)
> 3650 days = 10 years. That's not exactly "never expiring", but it does the
> trick for me (I use it for LDAP bind users).

Right, this will work as long as the expiration does not go over year 2038:
https://fedorahosted.org/freeipa/ticket/2496

This is the proper RFE to make "0" work:
https://fedorahosted.org/freeipa/ticket/2795
You can add yourself to CC to receive updates on it, it is now scheduled for
the next feature release.

Martin

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

Re: [Freeipa-users] Adding FreeIPA to an existing infrastructure

[Martin Kosek]

On 04/12/2016 12:14 PM, Remco Kranenburg wrote:
> Thanks for all the pointers. I'm tentatively moving forward with a CA-less and
> DNS-less IPA server, with Letsencrypt certificates. I think this is also the
> setup that is used by the demo at . Is
> there some documentation about this setup?

I installed this FreeIPA Demo server with Dogtag CA and then used something
like this to setup the root cert:


# do this once before taking snapshot of the VM
dnf install letsencrypt -y

ipa-cacert-manage install le-root-ca.pem -n le-root-ca -t ,,
ipa-certupdate -v

ipa-cacert-manage install le-authority-x1.pem -n le-authority-x1 -t C,,
ipa-certupdate -v


and then generated LE certificate:


# generate CSR
certutil -R -d /etc/httpd/alias/ -k Server-Cert -f /etc/httpd/alias/pwdfile.txt
-s "CN=$(hostname)" --extSAN "dns:$(hostname)" -a -o /root/httpd-csr.pem
openssl req -in /root/httpd-csr.pem -outform der -out /root/httpd-csr.der

# httpd process prevents letsencrypt from working, stop it
service httpd stop

# get a new cert
letsencrypt certonly --csr /root/httpd-csr.der --email ...@redhat.com 
--agree-tos

# remove old cert
certutil -D -d /etc/httpd/alias/ -n Server-Cert
# add the new cert
certutil -A -d /etc/httpd/alias/ -n Server-Cert -t ,, -a -i /root/_cert.pem

# start httpd with the new cert
service httpd start


but you probably do not want this as you are not installing CA piece.

> I'm trying to install a Letsencrypt
> certificate into FreeIPA, but when I run the installation:
> 
> ipa-server-install --http-cert-file cert.pem --http-cert-file privkey.pem
> --dirsrv-cert-file cert.pem --dirsrv-cert-file privkey.pem
> 
> It asks for my "Apache Server private key unlock password", even though the 
> key
> from Letsencrypt is not encrypted with a passphrase. When I give a bogus
> password, it gives me another error:
> 
> ipa.ipapython.install.cli.install_tool(Server): ERRORThe full certificate
> chain is not present in cert.pem, privkey.pem
> 
> Letsencrypt provides me with a few files: cert.pem, chain.pem, fullchain.pem,
> privkey.pem. Even when I also add chain.pem and fullchain.pem, it gives me the
> same error.

CCing JanC, he is the man to help with this one.

Martin

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

Re: [Freeipa-users] Announcing FreeIPA 4.3.1

[Martin Kosek]

On 03/24/2016 10:23 PM, Petr Vobornik wrote:
> The FreeIPA team would like to announce FreeIPA v4.3.1 bug fixing release!
> 
> It can be downloaded from http://www.freeipa.org/page/Downloads. The builds 
> are
> available for Fedora 24 and rawhide. Builds for Fedora 23 are available in the
> official COPR
> repository.
> Experimental builds for CentOS 7 will be available in the official FreeIPA
> CentOS7 COPR
> repository
> shortly after Easter Holidays.
> 
> This announcement with links to Trac tickets is available on
> http://www.freeipa.org/page/Releases/4.3.1 .
> 
> Fedora 24 update: https://bodhi.fedoraproject.org/updates/freeipa-4.3.1-1.fc24

For the record, I just finished upgrading FreeIPA Public Demo to version 4.3.1.
Besides other improvements noted on the release page, the good news is that the
FreeIPA demo web server now scores "A" in the SSL Labs SSL Server Test (the
cipher update is done automatically after upgrade to 4.3.1).

Martin

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

Re: [Freeipa-users] Centos 7 IPA server, Centos 6 Clients

[Martin Kosek]

On 04/06/2016 12:23 AM, Jeremy Utley wrote:
> Hello all!
> 
> Is there any known issues with registering a CentOS 6 client with a CentOS 7 
> FreeIPA server?  I just tried to register my first C6 client (fully updated) 
> with our new FreeIPA infrastructure installed on C7, and I'm getting an NSS 
> error:
> 
> args=/usr/sbin/ipa-join -s ds02.domain.com  -b 
> dc=ipa,dc=domain,dc=com -d
> stdout=
> stderr=XML-RPC CALL:
> 
> \r\n
> \r\n
> join\r\n
> \r\n
> \r\n
> hostname.domain.com 
> \r\n
> \r\n
> \r\n
> nsosversion\r\n
> 2.6.32-573.18.1.el6.x86_64\r\n
> nshardwareplatform\r\n
> x86_64\r\n
> \r\n
> \r\n
> \r\n
> 
> * About to connect() to ds02.domain.com  port 443 (#0)
> *   Trying 192.168.150.2... * Connected to ds02.domain.com 
>  (192.168.150.2) port 443 (#0)
> * Initializing NSS with certpath: sql:/etc/pki/nssdb
> *   CAfile: /etc/ipa/ca.crt
>CApath: none
> * NSS error -12190
> * Closing connection #0
> libcurl failed to execute the HTTP POST transaction.  SSL connect error
> 
> Looking up that NSS error, it seems to indicate a SSL protocol error.  
> Looking 
> at my FreeIPA webserver configuration, I'm allowing TLSv1.0, TLSv1.1, TLSv1.2:
> 
> The oddest part is that, from the client, I can use wget to connect to the 
> IPA 
> server, but can not use curl:
> 
> [root@hostname ~]# wget --no-check-certificate https://ds02.domain.com
> --2016-04-05 17:42:50-- https://ds02.domain.com/
> Resolving ds02.domain.com... 192.168.150.2
> Connecting to ds02.domain.com |192.168.150.2|:443... 
> connected.
> WARNING: cannot verify ds02.domain.com ’s 
> certificate, 
> issued by “/O=IPA.DOMAIN.COM/CN=Certificate 
>  Authority”:
>Self-signed certificate encountered.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: https://ds02.domain.com/ipa/ui [following]
> 
> 
> [root@hostname ~]# curl -v -k https://ds02.domain.com/
> * About to connect() to ds02.domain.com  port 443 (#0)
> *   Trying 192.168.150.2... connected
> * Connected to ds02.domain.com  (192.168.150.2) port 
> 443 
> (#0)
> * Initializing NSS with certpath: sql:/etc/pki/nssdb
> * warning: ignoring value of ssl.verifyhost
> * NSS error -12190
> * Closing connection #0
> * SSL connect error
> curl: (35) SSL connect error
> 
> However, the same curl command, run from another C7 host, works just fine.  
> Something incompatible in the NSS libraries maybe?
> 
> Thanks for any help you can provide!
> 
> Jeremy

Any chance it is related to this thread:
https://www.redhat.com/archives/freeipa-users/2016-March/msg00305.html
and is resolved just with nss update on the client side?

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

Re: [Freeipa-users] using sudo in ipa

[Martin Kosek]

On 04/01/2016 07:14 PM, Armstrong, Jeffrey wrote:
> Hi
> 
> I would like to know how to configure sudo in the IdM environment. I need to 
> know how to configure sudo access without asking for a password.
> 
> */Jeffrey Armstrong/*/–Senior ECS Engineer/
> 
> ECMS – Application Support Team
> 
> Office Phone – 770-270-7421
> 
> Cell Phone – 404-323-7386
> 
> For Email_GSOC logo_color

Hi,

There is some documentation here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/sudo.html

As for preventing asking the password, you can use "!authenticate" SUDO option
that is set in the FreeIPA SUDO rule.

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

Re: [Freeipa-users] Unable to join FreeIPA client to server

[Martin Kosek]

On 03/29/2016 04:42 PM, Adam Bishop wrote:
> On 29 Mar 2016, at 14:29, Adam Bishop  wrote:
>> I could use a bit of help resolving this - full client debug follows. Both 
>> systems are running nss 3.19.1 which *should* support TLS1.2., so I'm unsure 
>> where to start fixing this.
> 
> Turns out to be a little easier to solve than I thought; the CentOS 6 client 
> was running an older version of NSS than I thought it was.
> 
> ipa-client-3.0.0-47.el6.centos.1.x86_64 defaults to requiring tls1.2 , but 
> does not depend on a version of NSS that actually supports tls1.2.

I do not think it *requires* TLS 1.2, rather allows the said range - from TLS
1.0 to 1.2. This is the bug where the change was made:

https://bugzilla.redhat.com/show_bug.cgi?id=1154687

If an NSS Requires was not bumped properly (IIRC, we bumped just python-nss
Requires), it sounds as a bug. Bugzilla welcome!

Thanks,
Martin

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

Re: [Freeipa-users] Tracking Login Times

[Martin Kosek]

On 03/21/2016 06:56 PM, Rob Crittenden wrote:
> Bob wrote:
>> If each IPA server tracks time of last auth independently, then one ipa
>> server might disable an inactive account. But that account might be
>> active on another servers. In a fail over case where the server that
>> that account normally uses is down, the user would not have a usable
>> account.
>>
>> Is it possible to use the account policy plugin?  Or is there a way to
>> track time of last auth that is replicated.  I need to have accounts
>> that have been inactive for 90 days automatically disabled.
> 
> You can't use the account policy plugin but it isn't aware of Kerberos so it
> would miss potentially a lot of authentications.
> 
> You could modify replication agreements to not ignore this attribute but you
> potentially create a replication "storm", particularly early morning when
> everyone logs in at the same time.
> 
> In any case IPA password policy doesn't currently handle inactivity. There is 
> a
> ticket open: https://fedorahosted.org/freeipa/ticket/4975 (with a potential
> short-term workaround).

JFTR, this is the ticket with failed login replication RFE:
https://fedorahosted.org/freeipa/ticket/3700

Martin

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

Re: [Freeipa-users] Certificate profiles and CA ACLs for service principals

[Martin Kosek]

On 03/22/2016 05:55 AM, Fraser Tweedale wrote:
> On Fri, Mar 18, 2016 at 08:12:44PM +1100, earsdown wrote:
...
> To my fellow FreeIPA developers: are service groups a sensible RFE?
> Is there a reason why they have not been implemented?

It *is* sensible RFE and it was actually already filed!

https://fedorahosted.org/freeipa/ticket/5277

Please feel free to add yourself to CC to receive updates or even help us with
implementation.

Thanks,
Martin

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

Re: [Freeipa-users] Directory Search Question

[Martin Kosek]

On 03/18/2016 09:21 PM, Randy Morgan wrote:
> We have a FreeIPA Version 4.2 production installation that seems to have a
> limitation we cannot figure out how to overcome.  Users cannot search, from 
> the
> gui, for a specific user.  The only users who can perform a search for a
> specific user are full-admins, everyone else the search option does not
> respond, meaning that if you click on the magnifying glass, nothing happens. 
> We have a large number of groups, and they are managed by the group owner, who
> needs to be able to do a user search.  This appears to be a permissions issue,
> but we are not sure what we need to change to make it so that we can assign
> search capability to specific user groups.  Any help would be greatly 
> appreciated.

Hello Randy,

What permissions have you defined to allow your group admins to administer the
groups?

On my RHEL-7.2 machine, I tried setting up delegation like that:

# kinit admin
Password for admin@RHEL72:
# ipa group-add lab
# ipa permission-add --type group --right write --filter "(cn=lab)" --attrs
member can_manage_lab

# ipa user-add --first Lab --last Admin labadmin
# ipa passwd labadmin
# ipa role-add labadmin
# ipa privilege-add labadmin
# ipa role-add-member labadmin --users labadmin
# ipa role-add-privilege labadmin --privilege labadmin
# ipa privilege-add-permission labadmin --permissions labadmin
# ipa privilege-add-permission labadmin --permissions can_manage_lab
# ipa user-show labadmin
...
  Roles: labadmin
# ipa user-add --first Lab --last User labuser1
# ipa user-add --first Lab --last User labuser2

# kinit labadmin
Password for labadmin@RHEL72:
Password expired.  You must change it now.
Enter new password:
Enter it again:
# ipa group-add-member lab --users labuser1
  Group name: lab
  GID: 63241
  Member users: labuser1
-
Number of members added 1
-

When I tried to achieve similar with labadmin on
https://ipa.rhel72/ipa/ui/#/e/group/member_user/lab
it worked for me as well and I was able to manage lab group members in the UI.

HTH,
Martin

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

Re: [Freeipa-users] YUbiKey for HOTP auth

[Martin Kosek]

On 03/12/2016 04:47 PM, Brad Bendy wrote:
> Hi,
> 
> YubiKey supports HOTP it appears, but im having a heck of a time
> getting the token to add FreeIPA. The YubiKey tool gives me the OATH
> Token which is 6 bytes and the secret key in 20 bytes hex. Ive entered
> the secret key and OATH token into the "key" field, ive tried all
> algorithms and get the error of "invalid 'ipatokenotpkey': Non-base32
> digit found"
> 
> Am I missing something? Or is this just not possible at all? I can't
> find any documentation on Google saying how to set these up.
> 
> Thanks!

Just for the record, you are adding the Yubikey via FreeIPA Web UI? We also
have otptoken-add-yubikey command that makes adding tokens easy.

CCing Nathaniel to consider what we could do to make your use case easier.

-- 
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] read-only service account - aci

[Martin Kosek]

On 03/15/2016 04:28 AM, Prashant Bapat wrote:
> Anyone?
> 
> On 11 March 2016 at 22:12, Prashant Bapat  > wrote:
> 
> Hi,
> 
> I'm trying to use IPA's LDAP server as the user data base for an external
> application.
> 
> I have created a service account from ldif below.
> 
> 
> dn: uid=srv-ro,cn=sysaccounts,cn=etc,dc=example,dc=com
> changetype: add
> objectclass: account
> objectclass: simplesecurityobject
> uid: system
> userPassword: changeme!
> passwordExpirationTime: 20380119031407Z
> nsIdleTimeout: 0
> 
> 
> This works fine. My question is whats the ACI associated with this new 
> user?
> Does this user have read-only access to everything in LDAP ? Or should I
> add/tune the ACI.

This system user can now access all LDAP data that are allowed for
authenticated users. It should not have permission to actually write something
unless you allow any user write something.

You can see the FreeIPA system read permissions [1] to see what authenticated
users are allowed to read. At minimum, they can read more information about
users, group member and others:

# ipa permission-find --bindtype=all | grep "Permission name"
  Permission name: System: Read AD Domains
  Permission name: System: Read CA ACLs
  Permission name: System: Read CA Renewal Information
  Permission name: System: Read Certificate Profiles
  Permission name: System: Read DNA Configuration
  Permission name: System: Read Domain Level
  Permission name: System: Read Global Configuration
  Permission name: System: Read Group ID Overrides
  Permission name: System: Read Group Membership
  Permission name: System: Read HBAC Rules
  Permission name: System: Read HBAC Service Groups
  Permission name: System: Read HBAC Services
  Permission name: System: Read Host Membership
  Permission name: System: Read Hostgroup Membership
  Permission name: System: Read Hostgroups
  Permission name: System: Read Hosts
  Permission name: System: Read ID Ranges
  Permission name: System: Read ID Views
  Permission name: System: Read Netgroup Membership
  Permission name: System: Read Netgroups
  Permission name: System: Read OTP Configuration
  Permission name: System: Read Realm Domains
  Permission name: System: Read Replication Information
  Permission name: System: Read SELinux User Maps
  Permission name: System: Read Services
  Permission name: System: Read Sudo Command Groups
  Permission name: System: Read Sudo Commands
  Permission name: System: Read Sudo Rules
  Permission name: System: Read Trust Information
  Permission name: System: Read User Addressbook Attributes
  Permission name: System: Read User ID Overrides
  Permission name: System: Read User IPA Attributes
  Permission name: System: Read User Kerberos Attributes
  Permission name: System: Read User Membership

Martin

[1] http://www.freeipa.org/page/V4/Managed_Read_permissions

-- 
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] devconf.cz talks about FreeIPA

[Martin Kosek]

On 02/07/2016 07:56 PM, Alexander Bokovoy wrote:
...
> FreeIPA workshop by Torsted Scherf and German Parente
> Part1: https://youtu.be/cxRK1MExMsc?t=4m57s
> Part2: https://www.youtube.com/watch?v=RBzL1_3nKH4

Just for the record, the workshop was acknowledged as one of the best sessions
on Devconf! Which says a lot, given there was 200+ sessions!

http://devconf.cz/3-best-presentations

Martin

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

Re: [Freeipa-users] Lock screen when Smart Card is removed.

[Martin Kosek]

On 03/10/2016 08:36 PM, Michael Rainey (Contractor) wrote:
> Greetings,
> 
> I have been adding systems to my new domain and utilizing the smart card login
> feature.  To date the smart card login feature is working very well.  However,
> my group has been trying to implement locking the screen when the smart card 
> is
> removed, but have not been successful at making it work.  Does anyone have any
> suggestions as to what it would take to enable locking the screen when the
> smart card is removed.
> 
> Thank you in advance.

Hi Michal,

What system are you using? For Fedora/RHEL like systems, there is authconfig
that can set this up in PAM (--smartcardaction=0):

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/smartcards.html#authconfig-smartcards-cmd

HTH,
Martin

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

Re: [Freeipa-users] ipa-getcert and SELinux

[Martin Kosek]

On 03/07/2016 10:03 PM, Thomas Raehalme wrote:
> Hi!
> 
> I have setup certificates for Puppet as described here:
> http://www.freeipa.org/page/Using_IPA's_CA_for_Puppet
> 
> Unfortunately SELinux is giving me hard time when invoking "ipa-getcert
> request" to generate the private/public key for the Puppet agent
> (permission denied when trying to write the key pair to
> /var/lib/puppet/ssl).
> 
> Disabling SELinux temporarily solves the issue, but the same problem
> reappears when renewing the certificate (ipa-getcert reports status
> NEED_CERTSAVE_PERMS for the request).
> 
> What would be the proper way to enable the necessary permissions on SELinux?
> 
> Best regards,
> Thomas

Hi Thomas,

Just for the record, I moved the page to
http://www.freeipa.org/page/Howto/Using_IPA%27s_CA_for_Puppet
and linked it from
http://www.freeipa.org/page/HowTos#Certificates

I see there was a similar page in the past, now claimed as rather outdated:
http://jcape.name/2012/01/16/using-the-freeipa-pki-with-puppet/

-- 
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] user certificate ldap EXTERNAL authentication

[Martin Kosek]

On 03/05/2016 06:00 AM, Rob Crittenden wrote:
> Natxo Asenjo wrote:
>>
>> By the way, revoking the certificate does not block applications using
>> it from ldap.
>>
>> I can still access the ldap server using this cert/key pair *after*
>> revoking the certificate using ipa cert-revoke . In order to
>> block it I need to remove the seeAlso value of the user account, or the
>> certificate attribute.
>>
>> I do not know if this is a security issue, but maybe worthwhile
>> documenting just in case.
> 
> SSL/TLS servers don't automatically check for cert revocation. You need
> to add the CRL to the 389-ds NSS database periodically. I don't know for
> sure but I don't think 389-ds can use OCSP to validate incoming client
> certs. There is an IPA ticket in the backlog to investigate this for the
> web and ldap servers: https://fedorahosted.org/freeipa/ticket/3542
> 
> And yeah, as you discovered, managing the value of CmapLdapAttr is a
> poor man's revocation.

I saved Natxo's contributed article here:
http://www.freeipa.org/page/Howto/Client_Certificate_Authentication_with_LDAP
for now.

My take on this is that it probably works, but I am curious actually what
problem you are solving. Are you interested only in allowing Certificate
authentication with FreeIPA LDAP or rather in allowing certificate
authentication in your application, whatever are the means?

If this is the case, would leveraging SSSD Smart Card/certificate
authentication help? At minimum, it can lookup users by certificate:

https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate

With leveraging SSSD, you should be able to avoid manual user mapping in
FreeIPA LDAP. I am not sure though how the revocation would work. CCing Sumit
on this one.

Martin

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

Re: [Freeipa-users] user certificate ldap EXTERNAL authentication

[Martin Kosek]

On 03/05/2016 12:08 AM, Natxo Asenjo wrote:
> On Fri, Mar 4, 2016 at 11:00 PM, Simo Sorce  wrote:
> 
>> On Fri, 2016-03-04 at 14:34 -0500, Rob Crittenden wrote:
>>> Natxo Asenjo wrote:
>>
 when I go to http://www.freeipa.org/page/Special:OpenIDLogin to login
 with the fedora account I get


   OpenID error

 An error occurred: an invalid token was found.

 Return to Main Page .


 So, sorry, I cannot edit the contribute to the wiki. I will write
 something down in my own wiki and post the link here, search engines
 will index this mailing list posts as well, so this knowledge will not
 go lost.
>>>
>>> It's not just you. I can't login either. I think Martin will need to
>>> poke at this on Monday.
>>
>> I tried this just now and it worked, maybe there was an issue that has
>> since resolved itself ?
>>
> 
> no, same error.
> 
> O well, I have this howto, just copy paste it from my mediawiki (public
> domain):
> 
> https://asenjo.nl/wiki/index.php/Client_certificate_authentication_ipa

I checked and I was also able to log in. I suspect it is a problem with your
browser then, maybe testing it with a clear session would help.

-- 
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] version compatibility between server and client

[Martin Kosek]

On 02/29/2016 07:03 PM, Rakesh Rajasekharan wrote:
> the only reason for me to avoid ipa-client-install was few of our machines
> are Amazon Linux and I was having a tough time setting up ipa over there as
> the yum does not get the repo even with epel enabled.

Ah, right. This was already discussed to some extent there:
https://www.redhat.com/archives/freeipa-users/2016-February/msg00311.html

Amazon Linux does not really fly with FreeIPA and SSSD. So if you want to avoid
these painful processes, I would recommend either increasing the pressure on
Amazon Linux to support it or switching to other AMIs, like CentOS (or even 
RHEL).

> Otherwise, I was able to get this working on all of the other systems ,
> which are centos 6.3

Good! (note that 6.3 is pretty old, IPA server on this version is known to have
some bugs and gaps. Current version is 6.7 or even better, 7.2)

> Are there any documentations on setting IPA on an Amazon Linux, if not, the
> only option would to try compiling this.

CCing Alexander in case he has any resources. But as I said above, current
situation of FreeIPA&SSSD on Amazon Linux is not great.

> 
> Thanks,
> Rakesh
> 
> On Mon, Feb 29, 2016 at 5:23 PM, Martin Kosek  wrote:
> 
>> On 02/26/2016 05:23 PM, Rakesh Rajasekharan wrote:
>>> Hi!,
>>>
>>> I had successfully set up ipa in our qa environment, but since we are
>>> running cenots 6, i just got 3.0.25 version of IPA.
>>>
>>> I wanted to try out the latest 4.x version, for server by using a centos
>> 7
>>> OS. But have few questions regarding that
>>>
>>> Will there be compatibility issues, if I use a server at 4.x and clients
>> at
>>> 3.0.25
>>
>> Please see
>> http://www.freeipa.org/page/Client#Compatibility
>> There are plans for FreeIPA 4.4 to improve the "ipa" tool/API
>> compatibility too.
>>
>>> Another question is,
>>> >From the documentation, I see that theres an option to manually
>> configure a
>>> client where in we do not have to install freeipa-client using
>>> ipa-client-install
>>>
>>>
>> https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/linux-manual.html
>>
>> Please note that this is a quite old documentation, see here for other
>> options:
>> http://www.freeipa.org/page/Upstream_User_Guide
>>
>>> So that way , I can install the latest version of freeipa server and make
>>> my clients also be able to use the latest verison without actually
>>> installing it.
>>>
>>> But, are there any issues with this approach, and how does it differ from
>>> doing a ipa-client-install on the client machine.
>>
>> I can hardly imagine when manually configuring a FreeIPA client would be a
>> good
>> idea. In vast majority of cases, ipa-client-install is what you want, to
>> configure a client against newer or older FreeIPA server version.
>>
>> Martin
>>
> 

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

Re: [Freeipa-users] version compatibility between server and client

[Martin Kosek]

On 02/26/2016 05:23 PM, Rakesh Rajasekharan wrote:
> Hi!,
> 
> I had successfully set up ipa in our qa environment, but since we are
> running cenots 6, i just got 3.0.25 version of IPA.
> 
> I wanted to try out the latest 4.x version, for server by using a centos 7
> OS. But have few questions regarding that
> 
> Will there be compatibility issues, if I use a server at 4.x and clients at
> 3.0.25

Please see
http://www.freeipa.org/page/Client#Compatibility
There are plans for FreeIPA 4.4 to improve the "ipa" tool/API compatibility too.

> Another question is,
>>From the documentation, I see that theres an option to manually configure a
> client where in we do not have to install freeipa-client using
> ipa-client-install
> 
> https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/linux-manual.html

Please note that this is a quite old documentation, see here for other options:
http://www.freeipa.org/page/Upstream_User_Guide

> So that way , I can install the latest version of freeipa server and make
> my clients also be able to use the latest verison without actually
> installing it.
> 
> But, are there any issues with this approach, and how does it differ from
> doing a ipa-client-install on the client machine.

I can hardly imagine when manually configuring a FreeIPA client would be a good
idea. In vast majority of cases, ipa-client-install is what you want, to
configure a client against newer or older FreeIPA server version.

Martin

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

Re: [Freeipa-users] Not able to get kerberos ticket from keytab

[Martin Kosek]

On 02/26/2016 10:31 AM, Teik Hooi Beh wrote:
> And yes, i also need to include -s ipaserver in the get-ipakeytab command,
> otherwise it kept giving wrong usage error

Just for the record, this should no longer be needed from FreeIPA 4.3.0:
https://fedorahosted.org/freeipa/ticket/2203

> On Fri, Feb 26, 2016 at 10:29 PM, Teik Hooi Beh  wrote:
> 
>> Thanks. It's working now using ipa-getkeytab.
>>
>> Correct me if I am wrong (as I am new to freeipa), using ktutil I could
>> add multiple user in a keytab file (correct???) but in this case using
>> ipa-getkeytab can I do the same?
>>
>> On Fri, Feb 26, 2016 at 9:15 PM, David Kupka  wrote:
>>
>>> On 26/02/16 08:56, David Kupka wrote:
>>>
 On 26/02/16 02:22, Teik Hooi Beh wrote:

> Hi,
>
> I have manged to deployed 1 ipa master and 1 ipa client with success on
> centos 7.2 with freeipa v4.2. I also managed to create user and set
> sshd-rules to for ttester user and also successfully get krb ticket
> using *kinit
> ttes...@example.my*. I am trying to deploy password-less SSH login with
> kerberos using the following guide  (
>
> https://uz.sns.it/~enrico/wordpress/2014/03/password-less-ssh-login-with-kerberos/
> )
>
> -
>
> snippet -
>
>
>
> *$ ktutil ktutil: add_entry -password -p ttes...@example.my -k 1 -e
> aes256-cts-hmac-sha1-96 ktutil: write_kt keytab*
>
> When I tried *kinit -kt keytab ttes...@example.my*, I get *"**kinit:
> Password incorrect while getting initial credentials"*
> Doing a trace using KRB5_TRACE on both calls
>
> *1. KRB5_TRACE=/dev/stderr kinit ttes...@example.my*
> 27242] 1456447025.219676: Getting initial credentials for
> ttes...@example.my
> [27242] 1456447025.222070: Sending request (164 bytes) to EXAMPLE.MY
> [27242] 1456447025.23: Resolving hostname node1.example.my
> [27242] 1456447035.238004: Initiating TCP connection to stream
> 192.168.38.2:88
> [27242] 1456447035.238675: Sending TCP request to stream
> 192.168.38.2:88
> [27242] 1456447035.241248: Received answer (337 bytes) from stream
> 192.168.38.2:88
> [27242] 1456447035.241257: Terminating TCP connection to stream
> 192.168.38.2:88
> [27242] 1456447035.241377: Response was from master KDC
> [27242] 1456447035.241437: Received error from KDC:
> -1765328359/Additional
> pre-authentication required
> [27242] 1456447035.241484: Processing preauth types: 136, 19, 2, 133
> [27242] 1456447035.241499: Selected etype info: etype aes256-cts, salt
> "s`GD^,#=cA:Vr9hD", params ""
> [27242] 1456447035.241504: Received cookie: MIT
> Password for ttes...@example.my:
> [27242] 1456447062.215750: AS key obtained for encrypted timestamp:
> aes256-cts/73C6
> [27242] 1456447062.215815: Encrypted timestamp (for 1456447062.215315):
> plain 301AA011180F32303136303232363030333734325AA1050203034913,
> encrypted
>
> F9A2E97E916FC14D141690E151A25DCC00168361179C7F0ACDA94C7F58F3D50429780A5608A6B8623E355F2A5BD676F6FA5272D38FD05C8B
>
> [27242] 1456447062.215942: Preauth module encrypted_timestamp (2) (real)
> returned: 0/Success
> [27242] 1456447062.215948: Produced preauth for next request: 133, 2
> [27242] 1456447062.215965: Sending request (257 bytes) to EXAMPLE.MY
> [27242] 1456447062.216010: Resolving hostname node1.example.my
> [27242] 1456447072.229254: Initiating TCP connection to stream
> 192.168.38.2:88
> [27242] 1456447072.229655: Sending TCP request to stream
> 192.168.38.2:88
> [27242] 1456447072.236955: Received answer (722 bytes) from stream
> 192.168.38.2:88
> [27242] 1456447072.236974: Terminating TCP connection to stream
> 192.168.38.2:88
> [27242] 1456447072.237080: Response was from master KDC
> [27242] 1456447072.237117: Processing preauth types: 19
> [27242] 1456447072.237125: Selected etype info: etype aes256-cts, salt
> "s`GD^,#=cA:Vr9hD", params ""
> [27242] 1456447072.237131: Produced preauth for next request: (empty)
> [27242] 1456447072.237140: AS key determined by preauth: aes256-cts/73C6
> [27242] 1456447072.237199: Decrypted AS reply; session key is:
> aes256-cts/2A71
> [27242] 1456447072.237216: FAST negotiation: available
> [27242] 1456447072.237236: Initializing KEYRING:persistent:1000:1000
> with
> default princ ttes...@example.my
> [27242] 1456447072.237275: Storing ttes...@example.my ->
> krbtgt/example...@example.my in KEYRING:persistent:1000:1000
> [27242] 1456447072.237330: Storing config in
> KEYRING:persistent:1000:1000
> for krbtgt/example...@example.my: fast_avail: yes
> [27242] 1456447072.237345: Storing ttes...@example.my ->
>
> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY@X-CACHECONF
> :
>
> in KEYRING:persistent:1000:1000
> [27242] 1456447072.237371: Storing co

Re: [Freeipa-users] server installation but client part fails

[Martin Kosek]

On 02/23/2016 05:38 PM, lejeczek wrote:
> On 23/02/16 15:04, Rob Crittenden wrote:
>> lejeczek wrote:
>>> hi everybody
>>>
>>> I'm trying server installation but it fails, I think very last leg, and
>>> I was hoping you could suggest places which I should start looking at.
>>>
>>>[7/7]: configuring ipa-dnskeysyncd to start on boot
>>> Done configuring DNS key synchronization service (ipa-dnskeysyncd).
>>> Restarting ipa-dnskeysyncd
>>> Restarting named
>>> Restarting the web server
>>> ipa.ipapython.install.cli.install_tool(Server): ERROR Configuration of
>>> client side components failed!
>>> ipa-client-install returned: Command ''/usr/sbin/ipa-client-install'
>>> '--on-master' '--unattended' '--domain' '.private.my.private' '--server'
>>> '.private.my.private' '--realm' 'PRIVATE.MY.PRIVATE' '--hostname'
>>> '.private.my.private'' returned non-zero exit status 1
>>>
>>> many thanks
>>>
>> Look in /var/log/ipaserver-install.log and
>> /var/log/ipaclient-install.log for a more detailed reason.
>>
>> rob
>>
> thanks Rob, I was missing client part of logs.
> I just have to be careful with my finely grained configuration & config files.
> If anybody stumbles upon similar errors - first thing to do is to make sure
> your already existing httpd config(s) does not exclude *.conf from Apache's
> main dir, which is where IPA renders its files.
> 

This looks as a "+1" to this FreeIPA RFE:
https://fedorahosted.org/freeipa/ticket/4431

If we carry our own minimal hardened httpd.conf, issues like this should not
happen...

-- 
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] Traceback starting pki-cad - ca.subsystem.certreq missing?

[Martin Kosek]

On 02/20/2016 05:58 PM, Ian Pilcher wrote:
> I am running IPA 3.0.0 on CentOS 6 (32-bit x86), and I am getting a
> traceback every time pki-cad starts:
> 
> Traceback (most recent call last):
>   File "/usr/sbin/pki-server", line 89, in 
> cli.execute(sys.argv)
>   File "/usr/sbin/pki-server", line 84, in execute
> super(PKIServerCLI, self).execute(args)
>   File "/usr/lib/python2.6/site-packages/pki/cli.py", line 195, in execute
> module.execute(module_args)
>   File "/usr/lib/python2.6/site-packages/pki/server/cli/upgrade.py", line 103,
> in execute
> scriptlet.execute()
>   File "/usr/lib/python2.6/site-packages/pki/server/upgrade/__init__.py", line
> 50, in execute
> cert = self.subsystem.get_system_cert('subsystem')
>   File "/usr/lib/python2.6/site-packages/pki/server/__init__.py", line 93, in
> get_system_cert
> cert['request'] = base64.b64decode(self.config['%s.%s.certreq' %
> (self.prefix, tag)])
> KeyError: 'ca.subsystem.certreq'
> Starting pki-ca:   [  OK  ]
> 
> As you can see, the daemon does still start successfully, and the
> traceback doesn't appear in any of the pki-cad logs.
> 
> It seems that it is looking for a ca.subsystem.certreq entry in
> /etc/pki-ca/CS.cfg, and sure enough it isn't there.  Nor is it present
> in CS.cfg.bak.
> 
> How can I create this entry (or otherwise fix this)?
> 
> Thanks!

This looks as something PKI specific (given it is in /usr/sbin/pki-server),
CCing Endi from Dogtag team.

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

[Martin Kosek]

On 02/19/2016 06:33 AM, Chris Addie wrote:
> I have two separate networks each with their own FreeIPA server(s) and I
> would like for users from network A to be able to be able to access services
> in network B, but not the other way around. The documentation for ipa
> trust-add seems to imply this is not possibly however as “Only trusts to
> Active Directory domains are supported right now.” It seems really odd that
> FreeIPA supports trusting a Windows AD domain but not another FreeIPA
> domain. Is this really the case?

Yes.

> If so are IPA -> IPA trusts a feature that
> is planned for the future?

Yes :-)

> Is there some other way I could achieve this?

You can do hacks to achieve authentication part, but you would still miss
authorization or other parts. Please see details to my brief answer in our FAQ
section:

http://www.freeipa.org/page/Frequently_Asked_Questions#When_will_we_implement_FreeIPA_to_FreeIPA_trusts.3F

HTH,
Martin

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

Re: [Freeipa-users] freeipa permission denied for user

[Martin Kosek]

On 02/18/2016 02:11 PM, Rakesh Rajasekharan wrote:
> I set up freeipa on our environment and its works perfectly for most of the
> hosts.. but on few I am getting a permission denied.
> 
> [root@ipa-client-1c :~] ssh tempuser@localhost
> tempuser@localhost's password:
> Permission denied, please try again.
> tempuser@localhost's password:
> 
> 
> 
> 
> I checked the hbac, but that seems to be fine
> 
> root@ipa-master-test-1b ] ipa hbactest --user=tempuser --host=x.x.x.x
> --service=sshd
> 
> Access granted: True
> 
>   Matched rules: allow_all
> 
> 
> Another thing I noticed is the nsswitch.conf had the below entries after
> the freeipa installation
> passwd: files sss ldap
> shadow: files sss ldap
> group:  files sss ldap
> 
> hosts:  files dns
> 
> 
> bootparams: nisplus [NOTFOUND=return] files
> 
> ethers: files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:files
> services:   files sss
> 
> netgroup:   files sss ldap
> 
> publickey:  nisplus
> 
> automount:  files ldap
> aliases:files nisplus
> 
> sudoers: files sss
> 
> 
> The ldap shouldn't be there above I guess..
> 
> and from the logs, i have the below errors
> 
> ==> /var/log/secure <==
> Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=tempuser
> Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser
> Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): received for
> user tempuser: 4 (System error)
> Feb 18 03:29:35 ip-x-x-x-x sshd[24851]: Failed password for tempuser from
> x.x.x.x port 36687 ssh2
> Feb 18 03:29:39 ip-x-x-x-x sshd[24853]: Connection closed by x.x.x.x
> Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1  user=tempuser
> Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_sss(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=tempuser
> Feb 18 03:34:17 ip-x-x-x-x sshd[25108]: pam_sss(sshd:auth): received for
> user tempuser: 4 (System error)
> Feb 18 03:34:19 ip-x-x-x-x sshd[25108]: Failed password for tempuser from
> 127.0.0.1 port 59870 ssh2
> 
> 
> ==> /var/log/messages <==
> Feb 18 03:37:45 ip-x-x-x-x sssd[be[xyz.com]]: Shutting down
> Feb 18 03:37:45 ip-x-x-x-x sssd: Starting up
> Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: Starting up
> Feb 18 03:37:46 ip-x-x-x-x sssd[nss]: Starting up
> Feb 18 03:37:46 ip-x-x-x-x sssd[sudo]: Starting up
> Feb 18 03:37:46 ip-x-x-x-x sssd[pam]: Starting up
> Feb 18 03:37:46 ip-x-x-x-x sssd[pac]: Starting up
> Feb 18 03:37:46 ip-x-x-x-x sssd[ssh]: Starting up
> Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: dereference processing failed
> : Input/output error
> Feb 18 03:37:46 ip-x-x-x-x sssd[be[xyz.com]]: dereference processing failed
> : Input/output error
> Feb 18 03:38:41 ip-x-x-x-x [sssd[krb5_child[25324]]]: Permission denied
> Feb 18 03:38:41 ip-x-x-x-x [sssd[krb5_child[25324]]]: Permission denied

Could it be caused by /etc/krb5.conf permissions as here:
https://lists.fedorahosted.org/pipermail/sssd-users/2014-August/002103.html
?

Some advise is also here:
http://serverfault.com/questions/697113/linux-ad-integration-unable-to-login-when-using-windows-server-2012-dc

Martin

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

Re: [Freeipa-users] sudo runs despite being denied by HBAC rules

[Martin Kosek]

On 02/09/2016 05:06 PM, Ian Collier wrote:

Can anyone help me to understand these logs... is there maybe a bug here?

The basic situation is that there is no HBAC rule that would allow
sudo.  When people try it, sss accepts their password but then denies
them access to the sudo command.  But despite this, our logs still
contain some entries indicating that sudo was actually run. Of course
the sudoers file then denied them access and sent the sysadmin an
email.

Here's a journal extract:

Feb 09 11:34:58 hostname sudo[24453]: pam_unix(sudo:auth): authentication 
failure; logname= uid=12113 euid=0 tty=/dev/pts/1 ruser= rhost=  
user=
Feb 09 11:34:58 hostname sudo[24453]: pam_sss(sudo:auth): authentication 
success; logname= uid=12113 euid=0 tty=/dev/pts/1 ruser= rhost= 
user=
Feb 09 11:34:58 hostname audit[24453]:  pid=24453 uid=12113 auid=12113 ses=54 
msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="" 
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
Feb 09 11:34:58 hostname sudo[24453]: pam_sss(sudo:account): Access denied for 
user : 6 (Permission denied)
Feb 09 11:34:58 hostname audit[24453]:  pid=24453 uid=12113 auid=12113 ses=54 
msg='op=PAM:accounting grantors=? acct="" exe="/usr/bin/sudo" hostname=? addr=? 
terminal=/dev/pts/1 res=failed'
Feb 09 11:35:05 hostname sudo[24453]: pam_sss(sudo:auth): authentication 
success; logname= uid=12113 euid=0 tty=/dev/pts/1 ruser= rhost= 
user=
Feb 09 11:35:05 hostname audit[24453]:  pid=24453 uid=12113 auid=12113 ses=54 
msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="" 
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
Feb 09 11:35:05 hostname sudo[24453]: pam_sss(sudo:account): Access denied for 
user : 6 (Permission denied)
Feb 09 11:35:05 hostname audit[24453]:  pid=24453 uid=12113 auid=12113 ses=54 
msg='op=PAM:accounting grantors=? acct="" exe="/usr/bin/sudo" hostname=? addr=? 
terminal=/dev/pts/1 res=failed'
Feb 09 11:35:08 hostname sudo[24453]: pam_unix(sudo:auth): auth could not 
identify password for []
Feb 09 11:35:08 hostname sudo[24453]: pam_sss(sudo:auth): authentication 
failure; logname= uid=12113 euid=0 tty=/dev/pts/1 ruser= rhost= 
user=
Feb 09 11:35:08 hostname sudo[24453]: pam_sss(sudo:auth): received for user 
: 7 (Authentication failure)
Feb 09 11:35:08 hostname audit[24453]:  pid=24453 uid=12113 auid=12113 ses=54 
msg='op=PAM:authentication grantors=? acct="" exe="/usr/bin/sudo" hostname=? 
addr=? terminal=/dev/pts/1 res=failed'
Feb 09 11:35:08 hostname audit[24453]:  pid=24453 uid=12113 
auid=12113 ses=54 msg='cwd=2F6175xxx cmd=617074xxx terminal=pts/1 res=failed'
Feb 09 11:35:08 hostname audit[24453]:  pid=24453 uid=12113 
auid=12113 ses=54 msg='cwd=2F6175xxx cmd=617074xxx terminal=pts/1 res=failed'
Feb 09 11:35:08 hostname sudo[24453]:   : user NOT in sudoers ; TTY=pts/1 ; 
PWD=/x ; USER=root ; COMMAND=x
Feb 09 11:35:09 hostname sSMTP[24463]: Sent mail for r...@cs.ox.ac.uk (221 
mail.cs.ox.ac.uk closing connection) uid=0 =root outbytes=607

What this seems to say:

  1. pam_unix failed the password (expected because passwords are managed by 
IPA)
  2. pam_sss accepted the password
  3. pam_sss denied access to sudo:account

  Presumably sudo asked the user to try again and they re-typed the password

  4. pam_sss accepted the password
  5. pam_sss denied access to sudo:account

  6. Three seconds later pam_unix said it "could not identify password" (?)
  7. This time pam_sss failed the password and returned 7 (Authentication 
failure)
  8. sudo ran anyway!

I can't duplicate this behaviour myself but looking through the logs in
our computer lab there are a few of these.  See for instance the following
which appears to deny access three times and then just run it anyway:

Feb 02 10:31:12 hostname2 sudo[24468]: pam_unix(sudo:auth): authentication 
failure; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost=  
user=xyyx
Feb 02 10:31:14 hostname2 sudo[24468]: pam_sss(sudo:auth): authentication 
success; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost= 
user=xyyx
Feb 02 10:31:14 hostname2 audit[24468]:  pid=24468 uid=12106 auid=12106 ses=39 
msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="xyyx" 
exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
Feb 02 10:31:15 hostname2 sudo[24468]: pam_sss(sudo:account): Access denied for 
user xyyx: 6 (Permission denied)
Feb 02 10:31:15 hostname2 audit[24468]:  pid=24468 uid=12106 auid=12106 ses=39 
msg='op=PAM:accounting grantors=? acct="xyyx" exe="/usr/bin/sudo" hostname=? addr=? 
terminal=/dev/pts/1 res=failed'
Feb 02 10:31:26 hostname2 sudo[24468]: pam_sss(sudo:auth): authentication 
success; logname=xyyx uid=12106 euid=0 tty=/dev/pts/1 ruser=xyyx rhost= 
user=xyyx
Feb 02 10:31:26 hostname2 audit[24468]:  pid=24468 uid=12106 auid=12106 ses=39 
msg='op=PAM:authentica

Re: [Freeipa-users] OS migration from Fedora to CentOS?

[Martin Kosek]

On 02/05/2016 11:35 AM, Petr Vobornik wrote:
> On 02/04/2016 06:14 PM, Christophe TREFOIS wrote:
>> Hi all,
>>
>> We are currently running a 3-replica (all are setup with the —setup-ca flag)
>> cluster on Fedora 21, with FreeIPA 4.1.4.
>>
>> We would like to slowly upgrade to the new version and move away from Fedora
>> to CentOS 7.2.
>>
>> We were thinking of the following:
>>
>> - Create 3 CentOS machines with —setup-ca flag so that our current cluster 
>> is 6.
>> The first CentOS VM would then probably update the DB schema to the new
>> FreeIPA version.
>> - Remove the Fedora VMs 1 by 1 from the cluster using ipa-replica-manage del
>> 
>> - Be happy?
>>
>>
>> 1. Could you please advise if this is considered the safest practise?
> 
> More or less yes:
> 
> 1. create First IPA 4.2 against some FreeIPA 4.1.4 with CA
> 2. create the other two against the newly Created CentOS - will verify if it 
> is
> in a good shape
> 3. set new renewal CRL master:
> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master
> 4. Migrate DNA ranges using ipa-replica-manage tool
> 
> if all works well, remove all servers:
> 
> 5. remove CA repl. agreements for old servers using ipa-csreplica-manage del
> 6. remove old servers data and repl. agreements using ipa-replica-manage del
> 7. uninstall old servers using ipa-server-install --uninstall
> 
>> 2. Do we have to update to intermediate versions and if so how?
> 
> Should not be necessary.

Some advise is also present in the RHEL official docs:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc

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

Re: [Freeipa-users] Using external certificate in IPA 4.1

[Martin Kosek]

On 02/03/2016 06:02 PM, Ossi Ahosalmi wrote:
> I'm trying to use our organizations wildcard certificate in IPA. Certificate 
> is
> signed by a trusted CA.
> 
> Running:
> ipa-server-certinstall -w -d 
> 
> with next combinations:
> 
> - separate .key, .crt and ca chain, all in PEM format
> - .crt and ca bundled into one file, .key as a separate file
> - everything bundled together into one .p12 pkcs12 file
> 
> I always end up with this error:
> 
> "The full certificate chain is not present in ."
> 
> My CA file contains the whole chain and works in all other programs, just not
> in IPA.
> 
> 

CCing Jan, but I think you are hitting
https://fedorahosted.org/freeipa/ticket/5603

-- 
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] Obtaining certificate private keys for Apache/etc.

[Martin Kosek]

On 02/03/2016 12:42 AM, Christopher Young wrote:
> I've been doing some reading and perhaps I'm confusing myself, but I
> couldn't find any definitive guide on how to go about doing what I
> think it a pretty simple thing.
> 
> My ipa-client installs appear to generate a new TLS/SSL/PKI cert for
> each host when they are registered.  I'd like to utilize that
> certificate with Apache/tomcat/etc..  I'm aware of how to obtain the
> certificate itself, however I'm not clear on how to obtain the private
> key (in a format that I can use as well) that was used to generate the
> certificate.
> 
> Would someone kindly point me in the right direction or ideally just
> educate me on the command/options needed to do this.  In particular,
> I'm looking to create pem files for both the key and cert for use with
> Apache, but it would be useful to understand how to do it for other
> stores as well.  (Hint: this would be great to just have in a document
> that makes it clear). :)

Hi Chris,

I do not think it is a good idea to do what you are doing :-) The host
certificate does not need to be the same as Web certificate. From FreeIPA 4.1
(IIRC), it is not even requested by default on all clients.

I would rather recommend generating a separate certificate for the Web UI, we
have some walkthrough here:

http://www.freeipa.org/page/PKI#Requesting_a_new_certificate

> Thanks again to the freeipa team.  I love this product.

And I love to hear notes from the community like this, very rewarding!

-- 
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] "Installing the client"

[Martin Kosek]

On 02/02/2016 11:35 PM, Alexander Bokovoy wrote:
> On Tue, 02 Feb 2016, Simpson Lachlan wrote:
>> In the docs, there is a section called "Installing the client".
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#setting-up-clients
>>
>>
>> The very first step contains language that is not explained.
>>
>> "For a regular user system" has one install method, and "An
>> administrator machine" has another.
>>
>> There is no indication what an administrator machine might be used for
>> - is this a replica? Is it a system that can run ipa commands on behalf
>> of the ipa-server?
>>
>> What is the difference between a regular user system and an
>> administrator machine?
> If you want to administer IPA from the command line, you need to install IPA
> command line tools. This is what it calls as 'administrator machine'.
> 
> For a regular client system you wouldn't be running 'ipa' command, thus
> installing ipa-admintools is not needed.
> 
> I agree it is a bit terse there so it might be a good idea to file a
> documentation bug against 'ipa' component of RHEL 7.

I would suggest using the documentation component directly. Here is the direct
link for filing the bug:

https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=doc-Linux_Domain_Identity_Management_Guide

-- 
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] Joining a host

[Martin Kosek]

On 02/02/2016 11:35 PM, Simpson Lachlan wrote:
> Hola,
> 
> Presuming a regular machine, I've started the join as per instructions:
> 
> yum install ipa-client
> 
> [root@vmts-linux1 ~]# ipa-client-install
> Error checking LDAP: Operations error: 04DC: LdapErr: DSID-0C0906E8, 
> comment: In order to perform this operation a successful bind must be 
> completed on the connection., data 0, v1db1
> Discovery was successful!
> Client hostname: vmts-linux1.unix.example.org
> Realm: UNIX.EXAMPLE.ORG
> DNS Domain: unix.example.org
> IPA Server: dc1.example.org
> BaseDN: dc=unix,dc=example,dc=org
> 
> 
> There are two things here that I'd like to understand.
> 
> 1. There was an error, but the process seems to have been successful? Should 
> I be investigating that error or is it to be expected?

Hi Simpson,

I suspect that ipa-client-install had problems verifying a server during the
discovery, so it may have assumed some values itself, it probably did it wrong.
Details are in the ipaclient-install.log.

> 2. The IPA server is wrong - the machine it has found the PDC  server (with a 
> one way trust IPA->AD), but not the IPA server. I can only presume this is in 
> error and that I should run the command again explicitly stating the IPA 
> server?

So are you saying that FreeIPA actually discovered on an AD server? Do you DNS
domain with SRV records for FreeIPA set up? If yes, you can pass it via
"--domain" option of ipa-client-install, without using hard coded server list
via "--server" options.

-- 
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 smart card how to

[Martin Kosek]

On 02/02/2016 04:49 PM, Michael Rainey (Contractor) wrote:
> Greetings FreeIPA Community,
> 
> I have been testing and working with the smart card login feature of the IPA
> server, and have had some successes with this project. However, my latest
> server/client setup isn't working as expected.  I can where the problem is
> occurring, which is the Common Name on the Card is not being mapped to the
> proper attribute on the IPA server. So here's my question: Is there a howto
> which explains how an where this mapping occurs?  Is this something I can
> configure myself, or is hard coded.

At the moment, the Smart Card support present in SSSD looks up the user by
searching with a blob containing the whole SC certificate. This BTW means that
the certificate needs to be present at user entry in FreeIPA to make sure it
matches, no other mapping mechanism is available yet. We have some plans though:

http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping

If you are interested in HOWTOs, Nathan Kinder put together pretty neat blog
posts how to make Smart Card authentication working:

http://www.freeipa.org/page/V4/User_Certificates#References

HTH,
Martin

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

Re: [Freeipa-users] ca install fails upgrading to 4.2.0

[Martin Kosek]

On 02/02/2016 11:51 AM, Robert van Veelen wrote:
> Unfortunately not. I saw that thread and grabbed the patch and updated spec
> to give it a try. Same issue.
> cheers,

Ah, pity. Let me CC Endi in this thread then. I suspect he will be interested
in the same log files as in the referred thread.

> On Tue, 2 Feb 2016 at 08:46 Martin Kosek  wrote:
> 
>> On 02/02/2016 02:18 AM, Robert van Veelen wrote:
>>> Hi,
>>> I'm trying to create an ipa replica from
>>> ipa-server-3.0.0-47/pki-ca-9.0.3-45 to
>> ipa-server-4.2.0-15/pki-ca-10.2.5-6
>>> and cannot get the install to complete. The CS is configured as a sub to
>> an
>>> external CA. I keep getting the same error when running the
>>> replica-install. Digging into pki-ca's debug log, I find the following
>>> errors:
>>>
>>>  java.lang.Exception: SystemCertsVerification: system certs verification
>>> failure
>>> &
>>>  CertUtils: verifySystemCertByNickname() failed: caSigningCert
>> cert-pki-ca
>>>
>>> I've tried regenerating the source cacert.p12, upgrading pki-ca to
>> latest,
>>> etc. It just seems like the new replica is unable to verify the certs
>> while
>>> running selftests. any good tips for a next step to work out whats going
>> on?
>>>
>>> Thanks,
>>>
>>> -rob
>>
>> Can this be the same problem as answered by Endi here:
>> https://www.redhat.com/archives/freeipa-users/2016-January/msg00564.html
>> ?
>>
>>
> 

-- 
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: [Centos7.2 Freeipa 4.2] browser : your session has expired

[Martin Kosek]

On 02/02/2016 10:33 AM, Christopher Lamb wrote:
> 
> Hi Martin,
> 
> Good points
> 
> Web UI
> Cannot authenticate to Web UI
>Make sure that the user can authenticate in CLI, e.g. with kinit $USER
>--> yes the user can ssh to FreeIPA hosts, and can call kinit without
>error.
>Make sure that httpd, dirsrv and ipa_memcached services on the affected
>FreeIPA server are running. --> httpd, slapd and memcached all running
>(proved by pgrep -l)
>Make sure there are no related SELinux AVCs -- SELinux is disabled

That made me sad a little, I can only say:

http://stopdisablingselinux.com/ :-)

>Make sure that cookies are enabled on the client browser --> enabled
>Make sure that the time on the FreeIPA server is up to date and there is
>no (significant) clock skew (freeipa-users thread) --> no clock skew
>Search for any related errors in /var/log/httpd/error_log --> no errors
>today

Ok, thanks for ruling out the basic issues, I will let Petr and Alexander dive
in the others. When we discover the culprit, it would be nice to add it to this
list too.

> From: Martin Kosek 
> To:   Christopher Lamb/Switzerland/IBM@IBMCH,
> freeipa-users@redhat.com
> Cc:   Alexander Bokovoy 
> Date: 02.02.2016 09:53
> Subject:  Re: [Freeipa-users] Fw: [Centos7.2 Freeipa 4.2] browser : your
> session has expired
> 
> 
> 
> On 02/02/2016 09:49 AM, Christopher Lamb wrote:
>>
>>
>> Sorry, Notes is playing up, and sent the last before I could type any
> text!
>>
>> The POST /ipa/session/login_password is successful.
>>
>> but the POST /ipa/session/json  and  GET /ipa/session/login_kerberos both
>> give 401 unathorized
>>
>> Chris
> 
> Just to make sure we have covered all possible pit holes we have already
> gathered on our Troubleshooting page, did check all the advise in this list
> 
> http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI
> 
> ?
> 
> 
> 
> 

-- 
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: [Centos7.2 Freeipa 4.2] browser : your session has expired

[Martin Kosek]

On 02/02/2016 09:49 AM, Christopher Lamb wrote:
> 
> 
> Sorry, Notes is playing up, and sent the last before I could type any text!
> 
> The POST /ipa/session/login_password is successful.
> 
> but the POST /ipa/session/json  and  GET /ipa/session/login_kerberos both
> give 401 unathorized
> 
> Chris

Just to make sure we have covered all possible pit holes we have already
gathered on our Troubleshooting page, did check all the advise in this list

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

?

-- 
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] ca install fails upgrading to 4.2.0

[Martin Kosek]

On 02/02/2016 02:18 AM, Robert van Veelen wrote:
> Hi,
> I'm trying to create an ipa replica from
> ipa-server-3.0.0-47/pki-ca-9.0.3-45 to ipa-server-4.2.0-15/pki-ca-10.2.5-6
> and cannot get the install to complete. The CS is configured as a sub to an
> external CA. I keep getting the same error when running the
> replica-install. Digging into pki-ca's debug log, I find the following
> errors:
> 
>  java.lang.Exception: SystemCertsVerification: system certs verification
> failure
> &
>  CertUtils: verifySystemCertByNickname() failed: caSigningCert cert-pki-ca
> 
> I've tried regenerating the source cacert.p12, upgrading pki-ca to latest,
> etc. It just seems like the new replica is unable to verify the certs while
> running selftests. any good tips for a next step to work out whats going on?
> 
> Thanks,
> 
> -rob

Can this be the same problem as answered by Endi here:
https://www.redhat.com/archives/freeipa-users/2016-January/msg00564.html
?

-- 
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 Web Portal using outdated ciphers, breaking with some clients

[Martin Kosek]

On 01/29/2016 08:52 PM, Jeff Hallyburton wrote:
> Rob,
> 
> Chrome is flagging this, and given the error (I've attached a copy) its
> probably due to the cipher suite (possibly specifically that it uses
> SHA1).  This article has more details and is consistent with what we're
> seeing:
> 
> http://security.stackexchange.com/questions/83831/google-chrome-your-connection-to-website-is-encrypted-with-obsolete-cryptograph
> 
> We've also seen similar issues come up with other applications during
> penetration scans (e.g., Qualys) which is why I've noted it here.

Hello Jeff,

This is not because of TLS 1.2 would have a problem, but rather because of the
FreeIPA default selection of Apache ciphers. This is something being discussed
and fixed in this thread:

http://www.redhat.com/archives/freeipa-devel/2016-January/msg00369.html

and this ticket:
https://fedorahosted.org/freeipa/ticket/5589

After our initial tests (you can see results in the ticket), FreeIPA should no
longer receive this warning and should score "A" in the SSLabs test.

This change is expected to be released in 4.3.1 version, which is now in
development.

Martin

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

Re: [Freeipa-users] Client-Install failures

[Martin Kosek]

On 01/26/2016 10:20 PM, David Zabner wrote:

Hi All,
I am working on automated deployment of ipa clients through a program called 
salt and have been seeing an issue.
Specifically, calls to ipa.server.internal/ipa/json occasionally return a 500 
error. This tends to occur while using ipa-client-install and ipa-dns commands.

I am on free-ipa v 4.2.0 running on Centos 7 and will include the offending 
httpd error log.
Thanks for your help,
David


CCing Simo, I wonder if this error could be some problem caused by 
mod_auth_gssapi?

[Tue Jan 26 20:28:00.456181 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] mod_wsgi (pid=9535): Exception occurred processing WSGI 
script '/usr/share/ipa/wsgi.py'.
[Tue Jan 26 20:28:00.456211 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] Traceback (most recent call last):
[Tue Jan 26 20:28:00.456223 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File "/usr/share/ipa/wsgi.py", line 49, in application
[Tue Jan 26 20:28:00.456245 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] return api.Backend.wsgi_dispatch(environ, start_response)
[Tue Jan 26 20:28:00.456251 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 258, in __call__
[Tue Jan 26 20:28:00.456263 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] return self.route(environ, start_response)
[Tue Jan 26 20:28:00.456268 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 270, in route
[Tue Jan 26 20:28:00.456276 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] return app(environ, start_response)
[Tue Jan 26 20:28:00.456281 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 447, in __call__
[Tue Jan 26 20:28:00.456288 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] response = super(jsonserver, self).__call__(environ, 
 start_response)
[Tue Jan 26 20:28:00.456293 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 647, in __call__
[Tue Jan 26 20:28:00.456299 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] 'xmlserver', user_ccache, environ, start_response, headers)
[Tue Jan 26 20:28:00.456304 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py",line 593, in 
finalize_kerberos_acquisition
[Tue Jan 26 20:28:00.456310 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] session_data['ccache_data'] = load_ccache_data(ccache_name)
[Tue Jan 26 20:28:00.456315 2016] [:error] [pid 9535] [remote 
10.11.135.180:220]   File "/usr/lib/python2.7/site-packages/ipalib/session.py", 
line1231, in load_ccache_data
[Tue Jan 26 20:28:00.456330 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] src = open(name)
[Tue Jan 26 20:28:00.456344 2016] [:error] [pid 9535] [remote 
10.11.135.180:220] IOError: [Errno 2] No such file or directory: 
'/var/run/httpd/ipa/   clientcaches/admin@FOO.INTERNAL'


Martin

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

Re: [Freeipa-users] FREAK Vulnerability

[Martin Kosek]

On 01/26/2016 05:39 PM, Terry John wrote:
> Thanks for this. I've had a look today
> We are running:
> 
> ipa-server.x86_64 3.0.0-47.el6.centos
> 
> and some of the directives did not work, namely  allowWeakCipher, 
> sslVersionMin  and sslVersionMax . So I commented them out
> The ldapupdater then seems happy but when I went to restart IPA. The ldap 
> server wasn't happy with cipher TLS_RSA_WITH_AES_256_CBC_SHA256 and would not 
> start.

Usually, when DS is not starting after some change in configuration, you can
manually update the dse.ldif in /etc/dirsrv/... and start again.

As for RHEL-6 support, old SSL ciphers should be disabled since
ipa-3.0.0-46.el6, 389-ds-base-1.2.11.15-51.el6:

https://bugzilla.redhat.com/show_bug.cgi?id=1131049
https://bugzilla.redhat.com/show_bug.cgi?id=1153739

The options are normally used in RHEL-7.1+:
https://bugzilla.redhat.com/show_bug.cgi?id=1117979

they may have not been backported to RHEL-6 also, I am not sure.

> 
> Now I can't change anything and it doesn't work. Reaching for my backup.
> 
> Terry
> 
> -Original Message-
> From: Christian Heimes [mailto:chei...@redhat.com]
> Sent: 22 January 2016 10:03
> To: Terry John; Martin Kosek; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] FREAK Vulnerability
> 
> On 2016-01-21 17:54, Terry John wrote:
>> Thanks for the info. I have tried nearly all the NSSCipherSuite settings in 
>> that ticket but none so far has eliminated the FREAK report.
>> Christian thanks for the heads up on the syntax, I wasn't sure of what
>> I was doing
>>
>> Each time I've made a change I've run an sslscan from the OpenVAS scanner 
>> and I do get a different result each time but the errors still remains in 
>> OpenVAS.
>> Aaargh! Just noticed the port is 636/tcp(!) which is ns-slapd.
>>
>> Back to the drawing board :-)
> 
> Hi Terry,
> 
> you can give the attached file a try. It's a ldif file for ipa-ldap-updater. 
> You need to run the command on the machine as root and restart 389-DS.
> 
> The hardened TLS configuration is highly experimental and comes with no 
> warranty whatsoever. The configuration works on my tests systems with 
> Python's ldap client and Apache Directory Studio. It may not work with other 
> clients, especially older clients or clients in FIPS mode.
> 
> Christian
> 
> 
> 
> The Manheim group of companies within the UK comprises: Manheim Europe 
> Limited (registered number: 03183918), Manheim Auctions Limited (registered 
> number: 00448761), Manheim Retail Services Limited (registered number: 
> 02838588), Motors.co.uk Limited (registered number: 05975777), Real Time 
> Communications Limited (registered number: 04277845) and Complete Automotive 
> Solutions Limited (registered number: 05302535). Each of these companies is 
> registered in England and Wales with the registered office address of Central 
> House, Leeds Road, Rothwell, Leeds LS26 0JE. The Manheim group of companies 
> operates under various brand/trading names including Manheim Inspection 
> Services, Manheim Auctions, Manheim Direct, Manheim De-fleet and Manheim 
> Aftersales Solutions.
> 
> V:0CF72C13B2AC
> 
> 

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