[Freeipa-users] Re: I appear to have an issue with "hosts" on my replica

[Michael Papet via FreeIPA-users]

Have you tried the replication management script?
ipa-replica-manage(1): Manage IPA replica - Linux man page

  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
ipa-replica-manage(1): Manage IPA replica - Linux man page
 Manages the replication agreements of an IPA server. connect [SERVER_A] 
 - Adds a new replicatio...  |   |

  |

  |

 


  From: Grant Janssen 
 To: Michael Papet  
Cc: FreeIPA users list ; Justin Sheehy 
; Douglas Loeb 
 Sent: Tuesday, August 1, 2017 7:58 AM
 Subject: Re: [Freeipa-users] Re: I appear to have an issue with "hosts" on my 
replica
   
  The resolv.conf is identical on both systems, DNS is solid.  SRV records are 
functioning as expected.  I looked at everything and failing to find a 
resolution, sought advice here on the board.  Now that these are out of sync, 
how would one manually initiate a sync?  I haven’t found this in the 
documentation.
- grant

Grant,
Any ideas on this?  Everything appears to be in order, yet there is a disparity 
between the master and replica on the host count.



What's going on with DNS on these two hosts?  Are they pointing to the same DNS 
server?  Are there kerberos and ldap records.
mpapet

This e-mail and any attachments are intended only for use by the addressee(s) 
named herein and may contain confidential information. If you are not the 
intended recipient of this e-mail, you are hereby notified any dissemination, 
distribution or copying of this email and any attachments is strictly 
prohibited. If you receive this email in error, please immediately notify the 
sender by return email and permanently delete the original, any copy and any 
printout thereof. The integrity and security of e-mail cannot be guaranteed.

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

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

[Petr Vobornik via FreeIPA-users]

On Thu, Aug 3, 2017 at 9:57 PM, Alexandre Pitre via FreeIPA-users
 wrote:
> I'm unable to rejoin a CentOS client to my FreeIPA realm. I ran the
> uninstall command on my client: ipa-client-install --uninstall
>
> As far as I know the uninstall was successful. It asked me to reboot. After
> rebooting if I try to rerun the install command:
>
> ipa-client-install -U -p admin -w P@ssw0rd! --enable-dns-updates --mkhomedir
> --domain=customdomain.ad.com --realm=IPA.AD.COM --server=ipa01.ipa.ad.com
> --server=ipa02.ipa.ad.com --no-ntp --debug
>
> FYI, we're using a different  DNS domain than our freeIPA realm, hence why I
> have to provide all those flags.
>
> Running the install command failed. Here's the output from
> /var/log/ipa-client-uninstall.log
>
> 2017-08-03T19:17:58Z DEBUG stderr=
> 2017-08-03T19:17:58Z DEBUG trying to retrieve CA cert via LDAP from
> ipa-01.ipa.ad.com
> 2017-08-03T19:17:58Z DEBUG get_ca_certs_from_ldap() error:
> Insufficientaccess: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
> failure.  Minor code may provide more information (Server
> krbtgt/ad@ipa.ad.com not found in Kerberos database)
> 2017-08-03T19:17:58Z DEBUG Insufficient access: SASL(-1): generic failure:
> GSSAPI Error: Unspecified GSS failure.  Minor code may provide more
> information (Server krbtgt/ad@ipa.ad.com not found in Kerberos database)
> 2017-08-03T19:17:58Z ERROR In unattended mode without a One Time Password
> (OTP) or without --ca-cert-file You must specify --force to retrieve the CA
> cert using HTTP
> 2017-08-03T19:17:58Z ERROR Cannot obtain CA certificate HTTP certificate
> download requires --force
> 2017-08-03T19:17:58Z ERROR Installation failed. Rolling back changes.
> 2017-08-03T19:17:58Z ERROR IPA client is not configured on this system.
>
> Do I need to run/clean something else ? This error is consistent with all of
> the client I tried to re-join.
>
> Thanks for your help,
> Alex
>

Client uninstaller doesn't clean up host and dns records after itself.
The reason is that it doesn't run with the privileges as client
installer so it doesn't have rights to do the operations.

Normally you would get an error that your client is already joined and
needs to run it either with --force-join or delete the host record
from ipa with `ipa host-del $client` before reinstallation.

But in your case it fails much earlier on downloading CA certs from
master. Usually GSSAPI auth(using admin credentials with temp.
krb5.conf created based on provided params and autodiscovery) works in
this case and the cert is downloaded.

I'd try to remove the host from server first then try again. If it
doesn't help it would be also interesting to see log related to
previous installation step -  the kerberos configuration and TGT
obtaining - or full ipaclient-isntall.log).


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

[Freeipa-users] Re: setting up a new replica: failed in "retrieving schema for SchemaCache"

[Petr Vobornik via FreeIPA-users]

On Wed, Aug 2, 2017 at 3:06 PM, Karl Forner via FreeIPA-users
 wrote:
> Cross-posted from https://github.com/freeipa/freeipa-container/issues/151
>
> Context: I have one master running in a docker container, with freeIPA
> 4.2.3.
>
> I'm trying to setup a new replica. I could not using the same docker
> container version that runs the master. I've been told to use the latest
> version for the replica, that's what I tried here.
>
> The latest docker container should contain a freeIPa 4.4.4.
>
> When I launch the docker container, it launches the ipareplica-install
> process, it seems to go well but then fails with:
>
> 2017-08-02T11:54:20Z DEBUG retrieving schema for SchemaCache
> url=ldapi://%2fvar%2frun%2fslapd-QUARTZBIO-COM.socket
> conn= ance at 0x7fdb699aed88>
>
> What is the problem ? Is it because the master version is too old ?

The new replica cannot sync with older master. Why would be written in
Directory Server error log. I'd check the log both on master and
replica.

https://www.freeipa.org/page/Files_to_be_attached_to_bug_report#Directory_server_failed

>
> What should I do in order to setup a new replica ?
>
> Thanks.
>
> P.S
>
>
> The relevant part of the logs is :
> 2017-08-02T11:54:20Z DEBUG Successfully updated nsDS5ReplicaId.
> 2017-08-02T11:54:20Z DEBUG flushing
> ldapi://%2fvar%2frun%2fslapd-QUARTZBIO-COM.socket from SchemaCache
> 2017-08-02T11:54:20Z DEBUG retrieving schema for SchemaCache
> url=ldapi://%2fvar%2frun%2fslapd-QUARTZBIO-COM.socket
> conn= ance at 0x7fdb699aed88>
> 2017-08-02T11:54:37Z DEBUG Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
> 449, in start_creation
> run_step(full_msg, method)
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line
> 439, in run_step
> method()
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
> line 431, in __setup_replica
> r_bindpw=self.dm_password)
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
> line 1068, in setup_replication
> raise RuntimeError("Failed to start replication")
> RuntimeError: Failed to start replication
>
> 2017-08-02T11:54:37Z DEBUG   [error] RuntimeError: Failed to start
> replication
> 2017-08-02T11:54:37Z DEBUG Destroyed connection
> context.ldap2_140580366919440
> 2017-08-02T11:54:37Z DEBUG   File
> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in
> execute
> return_value = self.run()
>   File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line
> 318, in run
> cfgr.run()
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 310, in run
> self.execute()
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 334, in execute
> for nothing in self._executor():
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 376, in __runner
> exc_handler(exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 405, in _handle_execute_exception
> self._handle_exception(exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 395, in _handle_exception
> six.reraise(*exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 366, in __runner
> step()
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 363, in 
> step = lambda: next(self.__gen)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line
> 81, in run_generator_with_yield_from
> six.reraise(*exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line
> 59, in run_generator_with_yield_from
> value = gen.send(prev_value)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 597, in _configure
> next(executor)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 376, in __runner
> exc_handler(exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 405, in _handle_execute_exception
> self._handle_exception(exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 460, in _handle_exception
> self.__parent._handle_exception(exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 395, in _handle_exception
> six.reraise(*exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 457, in _handle_exception
> super(ComponentBase, self)._handle_exception(exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 395, in _handle_exception
> six.reraise(*exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 366, in __runner
> step()
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line
> 363, 

[Freeipa-users] Re: Extended Schema attributes missing

[Kristian Petersen via FreeIPA-users]

The customizations that define the additions to the schema appear to be in
the javascript file /usr/share/ipa/ui/js/plugins/chemuser/chemuser.js.  It
defines the additional fields we use that are causing us so much trouble.
I have included it below.

// Place in /usr/share/ipa/ui/js/plugins/chemuser/
define([
'freeipa/phases',
'freeipa/user'],
function(phases, user_mod) {

// helper function
function get_item(array, attr, value) {
 for (var i=0,l=array.length; i
wrote:

> On to, 03 elo 2017, Kristian Petersen via FreeIPA-users wrote:
>
>> The customizations are in separate files and are still there, but seem to
>> be getting ignored for lack of a better description.
>>
> You'd need to describe more and in more detail. Look at
> https://github.com/abbra/freeipa-desktop-profile/ as an example of an
> external plugin that works and integrates with existing FreeIPA upgrade
> code properly.
>
> You can look at that one to see what's different on your side.
>
> --
> / Alexander Bokovoy
>



-- 
Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Extended Schema attributes missing

[Rob Crittenden via FreeIPA-users]

Kristian Petersen via FreeIPA-users wrote:
> I work with Randy and there was some custom python and javascript code
> written to implement the extensions to the schema as I recall.

My initial thought was that the freeIPA code was updated directly and
updating overwrote the customizations.

rob

> 
> On Thu, Aug 3, 2017 at 8:15 AM, Rob Crittenden via FreeIPA-users
>  > wrote:
> 
> Randy Morgan via FreeIPA-users wrote:
> > When we setup our IPA server, we extended the schema to include 3 fields
> > that were important to the work we do.  When we performed the last
> > update, those fields still show as required, but they are missing and we
> > cannot add users to IPA unless we remove the required aspect of those
> > fields.  The problem is we need those fields.  Was there something in
> > the last update that relocated libraries or changed the locations for
> > extensions to the schema in IPA?  We are running RHEL 7.3 and IPA 4.4.0.
> >
> > Thanks in advance,
> >
> > Randy
> >
> 
> How did you extend the schema?
> 
> Did you update any python code in your previous work?
> 
> rob
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> 
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.org
> 
> 
> 
> 
> 
> -- 
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Deleting revoked certs from CA master

[Mark Haney via FreeIPA-users]

So now that we have a nicely replicating domain and ca, I'd like to rid 
myself of these revoked certificates which I tried as a way to fix the 
replication and setting up of a CA.  Is there a way to delete these 
certs out of the store?



--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.ha...@neonova.net
www.neonova.net
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: custom attributes as a part of default ipa permissions

[Alexander Bokovoy via FreeIPA-users]

On to, 03 elo 2017, Petr Fišer via FreeIPA-users wrote:

Hello,
We are currently deploying FreeIPA and we make use of custom attributes.
We defined them in custom.py script (located in 
/usr/lib/python2.7/site-packages/ipaserver/plugins/custom.py). 
custom.py looks like this:


from ipaserver.plugins.user import user
from ipalib.parameters import Int
from ipalib.parameters import Str
from ipalib import _
user.user.takes_params = user.user.takes_params + (
   Str('mailroutingaddress?',
   cli_name='mailroutingaddress'
   label=_('Mail routing address'),)
)

This works fine, server makes the attribute visible through API and 
also the "ipa" command can work with it. Basically, we made those 
attributes part of our default.
However, users (ordinary user in FreeIPA and also sysaccounts) cannot 
access those attributes when binding directly to the LDAP. This is due 
to ACI that FreeIPA writes into the LDAP.


I know that in FreeIPA:

* For user himself, ldap://self filter can be defined with "ipa
  selfservice-add 'some name' --attrs=mailroutingaddress
  --permissions=read" .
* For user to read attributes of other users, I can define permission,
  privilege and role and add this role to a user or group.
* For sysaccounts, it is advised to define custom ACI in the LDAP itself.

What I am thinking of: Is there any way that I can make FreeIPA 
re-generate its LDAP ACI based on our extended user class? Say let the 
IPA server load our custom.py which extends "user" with 
"mailroutingaddress" attribute and then call "ipa whatever" which 
effectively modifies FreeIPA's notion of user class and redefines the 
ACI?

You can use an approach I choose in FleetCommander plugin:
https://github.com/abbra/freeipa-desktop-profile/

In server plugin you'd define managed permissions:
https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/ipaserver/plugins/deskprofile.py#L146

Then when ipa-server-upgrade is run these permissions are automatically
converted into ACIs for any plugins.

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

[Freeipa-users] Re: Valid Sender ? - Re: Re: ipa-getcert and java certstore/keytool

[Jochen Hein via FreeIPA-users]

Rob Crittenden  writes:

> certmonger doesn't support storing certificates in a java keystore.

That's what I found out :-)

> The tricky bit might be in dealing with the CSR. certmonger needs the
> private key in order do the renewal.
>
> I guess one thing you could do is a straight ipa-getcert -f
> /path/to/cert.pem -k /path/to/key.pem ...  -C
> /path/to/your/post/script

Something like that might work and I hoped that someone might have done
and documented it before... 

> Then take the resulting PEM files, create a PKCS#12 file out of them,
> and import that into your java keystore.

That's what I'll try - let's see how that works out.

Jochen

-- 
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Extended Schema attributes missing

[Kristian Petersen via FreeIPA-users]

I work with Randy and there was some custom python and javascript code
written to implement the extensions to the schema as I recall.

On Thu, Aug 3, 2017 at 8:15 AM, Rob Crittenden via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Randy Morgan via FreeIPA-users wrote:
> > When we setup our IPA server, we extended the schema to include 3 fields
> > that were important to the work we do.  When we performed the last
> > update, those fields still show as required, but they are missing and we
> > cannot add users to IPA unless we remove the required aspect of those
> > fields.  The problem is we need those fields.  Was there something in
> > the last update that relocated libraries or changed the locations for
> > extensions to the schema in IPA?  We are running RHEL 7.3 and IPA 4.4.0.
> >
> > Thanks in advance,
> >
> > Randy
> >
>
> How did you extend the schema?
>
> Did you update any python code in your previous work?
>
> rob
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>



-- 
Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: IPA replica with CA role problems

[Mark Haney via FreeIPA-users]

On 08/03/2017 08:34 AM, Fraser Tweedale wrote:


Mark, that's great news; I'm glad you were able to resolve the
issue.

Everyone gets the tunnel vision sometimes :)

I wish you a successful rollout to production.

Cheers,
Fraser


Actually, let me update you on this.  I finally got a chance to speak to 
my colleague and he gave me information that wasn't included in his 
original email to me.  The issue was a lot bigger than pulling the certs 
out.  I'll try to keep this clear for anyone else in the same situation 
I found myself in.


IPA0 (the master) was installed and setup in mid-2016 sometime. It 
started out as freeipa v4.1.  One of the things I did when getting 
involved with getting a replica up and running for redundancy is to 
update the entire server.  It updated to the most recent version for 
CentOS 7.3, which is v4.4.  What didn't happen at that point was to 
increase the DOMAIN LEVEL to get the features available for v4.4.  IPA0 
stayed at Domain Level 0.  The replica I installed was on a new VM and 
was installed as v4.4.


It wasn't until my colleague dug up some google result about increasing 
the domain level when doing an upgrade of freeipa that we found this 
issue.  When he upped the Domain level to 1, then on IPA1 ran 
'ipa-client-install' and 'ipa-replica-install --setup-ca' did everything 
work.  He only noticed that when he tried 'ipa-replica-install 
--setup-ca' on IPA1, the installer barked about installing the client 
first THEN upgrading to a replica.


I didn't install the client when building IPA1, which may have 
contributed to the problems. If I had, the replica /probably/ would have 
had the CA setup just fine, just only with the v4.1 features even if the 
package was v4.4 on both servers because the domain level wouldn't have 
changed.


Unfortunately, the documentation is so jacked up and sparse, it took two 
of us two weeks plus to figure all this out.


I hope this helps someone else in the future.

--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.ha...@neonova.net
www.neonova.net
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA and postfix issue.

[Rob Crittenden via FreeIPA-users]

Bob Rentschler wrote:
> The query mismatch was a typo/mispaste, sorry about that.
> 
> It was indeed at least partly permissions in the LDAP server, likely
> because a service is running the query.
> 
> I solved the freeipa permissions with the below command, which is likely
> bad in some way but did allow postmap to return the 
> desired attributes:
> 
> ipa permission-mod "System: Read User Standard Attributes"
> --includedattrs=mail --includedattrs=mailAlternateAddress
> 
> The attributes have been changed today, I am
> using (|(mail=%s)(mailAlternateAddress=%s)) now that the simple
> (mail-%s) works.
> 
> Is there a better or more proper way? That one seems to allow anonymous
> enumeration of email accounts, which isn't a huge
> problem for me, but I could see cases where it would be. It also seems a
> waste to set up gssapi and TLS then weaken the LDAP
> ACI's.

You could use "System: Read User Addressbook Attributes" instead which
requires an authenticated user.

> 
> When I looked in the access log of the LDAP server I saw no error codes
> as such, was /var/log/dirsrv/slapd-/access the wrong file to
> look in.

That's right but LDAP errors can be subtle.

> The remaining issue is posmap returns results just fine, but postfix
> itself somehow fails to read the ldap alias map. I'll beat my
> head on that for a few hours now.
> 
> For the interested the relevant section of main.cf  is
> 
> virtual_alias_domains = domain.org 
> virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf
> 
> 
> All of the TLS functions are working properly, the directory server
> shows this when postfix connects:
> 
> 
> [03/Aug/2017:10:18:31.380423718 -0400] conn=95 op=0 SRCH
> base="cn=users,cn=accounts,dc=domain,dc=ord" scope=2
> filter="(|(mail=existing_u...@domain.org
> )(mailAlternateAddress=existing_u...@domain.org
> ))" attrs="uid"
> [03/Aug/2017:10:18:31.381151196 -0400] conn=95 op=0 RESULT err=0 tag=101
> nentries=1 etime=0

It is the err I was looking for. err=0 is good, though there are others
that can be acceptable as well depending on context. In this case one
user was found with the e-mail address.

> it also shows a few extras, I believe I need to tighetn up what postfix
> looks for as these are queries related to the sending email account.
> 
> [03/Aug/2017:10:18:32.201190867 -0400] conn=96 op=1 SRCH
> base="cn=users,cn=accounts,dc=domain,dc=org" scope=2
> filter="(|(mail= from>)(mailAlternateAddress=))" attrs="uid"
> [03/Aug/2017:10:18:32.201454459 -0400] conn=96 op=1 RESULT err=0 tag=101
> nentries=0 etime=0
> [03/Aug/2017:10:18:32.201883216 -0400] conn=96 op=2 SRCH
> base="cn=users,cn=accounts,dc=notwise,dc=net" scope=2
> filter="(|(mail=@)(mailAlternateAddress=@ domain>))" attrs="uid"
> [03/Aug/2017:10:18:32.202028213 -0400] conn=96 op=2 RESULT err=0 tag=101
> nentries=0 etime=0

Hard to say without knowing your LDAP db but these could be perfectly
normal and expected. It is searching the right subtree and the query
format looks right, that's about all I can say :-)

rob

> 
> Thanks!
> Bob
> 
> On Thu, Aug 3, 2017 at 10:06 AM, Rob Crittenden  > wrote:
> 
> Bob Rentschler via FreeIPA-users wrote:
> > This may be related to the issue discussed here:
> > 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/
> 
> 
> > 
>  
> >
> >
> > But it seems not to be, layer 8 is still open though.
> >
> > Using the instructions here
> > 
> https://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/
> 
> 
> > to enable postfix virtual users from freeIPA I seem to have hit a
> > sticking point in that postfix is unable to fetch the mail attribute.
> >
> > this is the query filter I modified as per the referenced email in the
> > archive.
> >
> > query_filter = (&(objectclass=posixaccount)(mail=%s))
> >
> > When run from postmap it gets nothing. If I change it for testing to
> > search by uid or another attribute it works as expected. a simple filter
> > like (uid=%s) works everytime.
> >
> > This ldapsearch run using the postfix servers keytab as credentials
> > works as well:
> >
> > ldapsearch -LLL -Y GSSAPI -b 

[Freeipa-users] Re: FreeIPA and postfix issue.

[Bob Rentschler via FreeIPA-users]

The query mismatch was a typo/mispaste, sorry about that.

It was indeed at least partly permissions in the LDAP server, likely
because a service is running the query.

I solved the freeipa permissions with the below command, which is likely
bad in some way but did allow postmap to return the
desired attributes:

ipa permission-mod "System: Read User Standard Attributes"
--includedattrs=mail --includedattrs=mailAlternateAddress

The attributes have been changed today, I am
using (|(mail=%s)(mailAlternateAddress=%s)) now that the simple (mail-%s)
works.

Is there a better or more proper way? That one seems to allow anonymous
enumeration of email accounts, which isn't a huge
problem for me, but I could see cases where it would be. It also seems a
waste to set up gssapi and TLS then weaken the LDAP
ACI's.

When I looked in the access log of the LDAP server I saw no error codes as
such, was /var/log/dirsrv/slapd-/access the wrong file to look in.

The remaining issue is posmap returns results just fine, but postfix itself
somehow fails to read the ldap alias map. I'll beat my
head on that for a few hours now.

For the interested the relevant section of main.cf is

virtual_alias_domains = domain.org
virtual_alias_maps = ldap:/etc/postfix/ldap_aliases.cf

All of the TLS functions are working properly, the directory server shows
this when postfix connects:


[03/Aug/2017:10:18:31.380423718 -0400] conn=95 op=0 SRCH
base="cn=users,cn=accounts,dc=domain,dc=ord" scope=2 filter="(|(mail=
existing_u...@domain.org)(mailAlternateAddress=existing_u...@domain.org))"
attrs="uid"
[03/Aug/2017:10:18:31.381151196 -0400] conn=95 op=0 RESULT err=0 tag=101
nentries=1 etime=0

it also shows a few extras, I believe I need to tighetn up what postfix
looks for as these are queries related to the sending email account.

[03/Aug/2017:10:18:32.201190867 -0400] conn=96 op=1 SRCH
base="cn=users,cn=accounts,dc=domain,dc=org" scope=2
filter="(|(mail=)(mailAlternateAddress=))" attrs="uid"
[03/Aug/2017:10:18:32.201454459 -0400] conn=96 op=1 RESULT err=0 tag=101
nentries=0 etime=0
[03/Aug/2017:10:18:32.201883216 -0400] conn=96 op=2 SRCH
base="cn=users,cn=accounts,dc=notwise,dc=net" scope=2
filter="(|(mail=@)(mailAlternateAddress=@))" attrs="uid"
[03/Aug/2017:10:18:32.202028213 -0400] conn=96 op=2 RESULT err=0 tag=101
nentries=0 etime=0

Thanks!
Bob

On Thu, Aug 3, 2017 at 10:06 AM, Rob Crittenden  wrote:

> Bob Rentschler via FreeIPA-users wrote:
> > This may be related to the issue discussed here:
> > https://lists.fedorahosted.org/archives/list/freeipa-
> us...@lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/
> >  us...@lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/>
> >
> > But it seems not to be, layer 8 is still open though.
> >
> > Using the instructions here
> > https://www.dalemacartney.com/2013/03/14/deploying-postfix-
> with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/
> > to enable postfix virtual users from freeIPA I seem to have hit a
> > sticking point in that postfix is unable to fetch the mail attribute.
> >
> > this is the query filter I modified as per the referenced email in the
> > archive.
> >
> > query_filter = (&(objectclass=posixaccount)(mail=%s))
> >
> > When run from postmap it gets nothing. If I change it for testing to
> > search by uid or another attribute it works as expected. a simple filter
> > like (uid=%s) works everytime.
> >
> > This ldapsearch run using the postfix servers keytab as credentials
> > works as well:
> >
> > ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=org
> > '(&(objectclass=posixaccount)(|(mail=validu...@example.org
> > )))'
> >
> > The FreeIPA version is 4.4.4 running on Fedora 26
> >
> > Is there something I may be overlooking here? I dove off into IPA v4
> > permissions and everything *seems* ok, but it is my chief suspect right
> now.
>
> When postmap gets nothing, is the LDAP query correct? What is the LDAP
> error code?
>
> The query you ran doesn't match the query_filter you posted. I mention
> it in case this wasn't just a typo in the e-mail.
>
> rob
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Extended Schema attributes missing

[Rob Crittenden via FreeIPA-users]

Randy Morgan via FreeIPA-users wrote:
> When we setup our IPA server, we extended the schema to include 3 fields
> that were important to the work we do.  When we performed the last
> update, those fields still show as required, but they are missing and we
> cannot add users to IPA unless we remove the required aspect of those
> fields.  The problem is we need those fields.  Was there something in
> the last update that relocated libraries or changed the locations for
> extensions to the schema in IPA?  We are running RHEL 7.3 and IPA 4.4.0.
> 
> Thanks in advance,
> 
> Randy
> 

How did you extend the schema?

Did you update any python code in your previous work?

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

[Freeipa-users] Re: ipa-getcert and java certstore/keytool

[Rob Crittenden via FreeIPA-users]

Jochen Kellner via FreeIPA-users wrote:
> Hi,
> 
> 3. August 2017 03:03, "Fraser Tweedale via FreeIPA-users" 
> 
> schrieb:
> 
>> On Wed, Aug 02, 2017 at 11:11:09PM +0200, Jochen Hein via FreeIPA-users 
>> wrote:
>>> I'm playing around with keycloak and wanted to use an SSL certificate
>>> from IPA. I've looked around but didn't see any howto about using java
>>> keytool with ipa-getcert. Has someone experience with it?
>>>
>> Might as well jump straight to commands/logs :)
> 
> I did some more research yesterday and finally got a certificate
> along the following lines:
> 
> - Generate a java keystore with keytool as described in the keycloak docs.
> - Generate a csr with keytool and paste it into Freeipa.
> - Got a certificate back from Freeipa.
> - Import the certificate into keytool (again keycloak docs).
> 
> My first tries had the cert attributes wrong, but I think I now got it right,
> but need to check with chrome to be sure. I'll post my steps later.
> 
> I was not successful in creating a certificate with ipa-getcert and
> import the key into keytool. But I'll try to get something monitored by
> certmonger - otherwise I'm sure the cert would expire... 

certmonger doesn't support storing certificates in a java keystore.

certmonger has the concept of pre and post renewal scripts so you can,
for example stop or start a service, or import a renewed certificate
somewhere else (IPA uses this to store a copy of some certificates in LDAP).

So theoretically certmonger could for example, track PEM files in the
filesystem and upon renewal run a post script to import the updated cert
into the java keystore.

The tricky bit might be in dealing with the CSR. certmonger needs the
private key in order do the renewal.

I guess one thing you could do is a straight ipa-getcert -f
/path/to/cert.pem -k /path/to/key.pem ...  -C
/path/to/your/post/script

Then take the resulting PEM files, create a PKCS#12 file out of them,
and import that into your java keystore. Then all renewals will run that
post-script which you can setup to update the cert in the java keystore.
I guess.

I don't know much at all about java so there is a lot of hand waving
going on. I hope some of it makes some sense/is doable.

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

[Freeipa-users] Re: FreeIPA and postfix issue.

[Rob Crittenden via FreeIPA-users]

Bob Rentschler via FreeIPA-users wrote:
> This may be related to the issue discussed here: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/SC7GYMHMJ2DNT6BDDSWG5F4HL252EJOD/
> 
> 
> But it seems not to be, layer 8 is still open though.
> 
> Using the instructions here
> https://www.dalemacartney.com/2013/03/14/deploying-postfix-with-ldap-freeipa-virtual-aliases-and-kerberos-authentication/
> to enable postfix virtual users from freeIPA I seem to have hit a
> sticking point in that postfix is unable to fetch the mail attribute.
> 
> this is the query filter I modified as per the referenced email in the
> archive.
> 
> query_filter = (&(objectclass=posixaccount)(mail=%s))
> 
> When run from postmap it gets nothing. If I change it for testing to
> search by uid or another attribute it works as expected. a simple filter
> like (uid=%s) works everytime.
> 
> This ldapsearch run using the postfix servers keytab as credentials
> works as well:
> 
> ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=org
> '(&(objectclass=posixaccount)(|(mail=validu...@example.org
> )))'
> 
> The FreeIPA version is 4.4.4 running on Fedora 26
> 
> Is there something I may be overlooking here? I dove off into IPA v4
> permissions and everything *seems* ok, but it is my chief suspect right now.

When postmap gets nothing, is the LDAP query correct? What is the LDAP
error code?

The query you ran doesn't match the query_filter you posted. I mention
it in case this wasn't just a typo in the e-mail.

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

[Freeipa-users] Re: Creating certificate for master domain

[Rob Crittenden via FreeIPA-users]

Rafał Wądołowski wrote:
> Okey, but how can I create certificate for domain intra.example.com?
> 
> I can't create host, because the hostname is required. When I try to add
> service, I got output that principal is required.

Like I said, every cert needs to live in a bucket (user, service, etc)
so since domain can't fit into one, you can't issue a cert for it.

What would it be used for? I'm not sure how meaningful a domain name in
a cert is, but it could be a use-case we missed.

rob

> 
> 
> Pozdrawiam,
> 
> Rafał Wądołowski
> 
> On 02/08/17 15:55, Rob Crittenden via FreeIPA-users wrote:
>> Rafał Wądołowski via FreeIPA-users wrote:
>>> Hi,
>>>
>>> I have freeipa 4.4 cluster with CN intra.example.com.
>>>
>>> We developed intranet on this same domain, but I can't create a valid
>>> certificate for it.
>>>
>>> I can't create service, because hostname is required. Is it other way to
>>> sign the CSR?
>>>
>>> What is the good practice for creating https certificates?
>>>
>> I don't understand the question.
>>
>> A certificate can only be issued for objects that IPA knows about, a
>> service, host or user.
>>
>> rob
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: IPA replica with CA role problems

[Fraser Tweedale via FreeIPA-users]

On Thu, Aug 03, 2017 at 07:18:30AM -0400, Mark Haney wrote:
> On 08/02/2017 04:17 PM, Fraser Tweedale wrote:
> > 
> > > - /var/log/ipareplica-install.log from replica
> > > - /etc/pki/pki-tomcat/ca/debug from both master and replica
> > > 
> > > Those logs should do for a start.
> > > 
> > > I'd also like to see your /etc/pki/pki-tomcat/ca/CS.cfg from both
> > > master and replica.  Depending on where investigation goes I might
> > > ask for some LDAP entries too, but I'm not up to that point yet.
> > > 
> > > Feel free to send logs directly to me and/or redact them as you see
> > > fit.
> > > 
> > Oh, and which version of IPA are you creating the replica from?
> > 
> > Thanks,
> > Fraser
> 
> Actually that won't be necessary, it took two of us looking at it, but we
> figured out the problem.  Based on what I can gather, when IPA0 was built,
> kinit admin wasn't run prior to updating the GoDaddy certs.  (The
> documentation isn't real clear on that, if said documentation was perused
> while setting it up.  As I said, I didn't build the server.)  Once the GD
> cert files were pulled from nssdb on IPA0 and reinstalled and updated with
> kinit admin ipa-certupdate, it seems to have cleared up the wonky
> configuration on that side.
> 
> Then, we went the nuclear option and removed the ipa-server packages from
> IPA1, re-installed them, ran ipa-client-install (which I didn't run and
> wasn't clear that it needed to be run), then run the ipa-replica-install
> --setup-ca and now everything is kosher.
> 
> I was fairly certain as I got into debugging it that it wasn't a bug, as the
> documentation tells you different things depending on what documentation you
> look at (ie, RH vs FreeIPA docs), so wasn't sure where the issue lie.   Most
> of the time, I had focused on something not right with IPA1, not really
> considering IPA0 could be jacked up in its own special way.  It was my
> colleague who reminded me there were two parts to the equation.  Tunnel
> vision still gets me even after 20 years of doing this!
> 
> Now though, we're up and running fine and ready to being a real rollout to
> our production servers.
> 
> I appreciate all the help from the list.
> 
Mark, that's great news; I'm glad you were able to resolve the
issue.

Everyone gets the tunnel vision sometimes :)

I wish you a successful rollout to production.

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

[Freeipa-users] Re: PKI debug files are not rotated

[Florence Blanc-Renaud via FreeIPA-users]

On 08/03/2017 11:19 AM, Harald Dunkel via FreeIPA-users wrote:

Hi folks,

I found some very large log files in

/var/log/pki/pki-tomcat/ca

On the major CA host the "debug" file is >1GByte and was never
rotated. It seems that there is a responsible config file /etc/\
pki/pki-tomcat/ca/CS.cfg, setting

debug.append=true
debug.enabled=true
debug.filename=/var/lib/pki/pki-tomcat/logs/ca/debug
debug.hashkeytypes=
debug.level=0
debug.showcaller=false

Maybe I am too blind to see, but I haven't found an appropriate
menu in the web interface to alter these settings. Is it safe to
edit this file on the command line, bypassing the ipa web or
command line interfaces? How can I enable log file rotation?

This is Freeipa 4.4.0 on Centos 7.3.


Every helpful comment is highly appreciated
Harri


Hi,

the following wiki [1] states that "The framework only supports file 
output without log rotation" so I understand that this behavior is 
expected. A ticket is already tracking the issue: 814 [2]


Flo

[1] http://pki.fedoraproject.org/wiki/Logging_Frameworks
[2] https://pagure.io/dogtagpki/issue/814
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: custom attributes as a part of default ipa permissions

[Petr Fišer via FreeIPA-users]

Oh, sorry, I forgot.

FreeIPA 4.4.0 on RHEL 7.

Petr Fišer

BCV solutions s.r.o.
Mobile: +420 607 618 243
E-mail: petr.fi...@bcvsolutions.eu
Jabber: petr.fi...@bcvsolutions.eu

On 08/03/2017 02:05 PM, Petr Fišer wrote:

Hello,
We are currently deploying FreeIPA and we make use of custom attributes.
We defined them in custom.py script (located in 
/usr/lib/python2.7/site-packages/ipaserver/plugins/custom.py). 
custom.py looks like this:


from ipaserver.plugins.user import user
from ipalib.parameters import Int
from ipalib.parameters import Str
from ipalib import _
user.user.takes_params = user.user.takes_params + (
Str('mailroutingaddress?',
cli_name='mailroutingaddress'
label=_('Mail routing address'),)
)

This works fine, server makes the attribute visible through API and 
also the "ipa" command can work with it. Basically, we made those 
attributes part of our default.
However, users (ordinary user in FreeIPA and also sysaccounts) cannot 
access those attributes when binding directly to the LDAP. This is due 
to ACI that FreeIPA writes into the LDAP.


I know that in FreeIPA:

  * For user himself, ldap://self filter can be defined with "ipa
selfservice-add 'some name' --attrs=mailroutingaddress
--permissions=read" .
  * For user to read attributes of other users, I can define
permission, privilege and role and add this role to a user or group.
  * For sysaccounts, it is advised to define custom ACI in the LDAP
itself.

What I am thinking of: Is there any way that I can make FreeIPA 
re-generate its LDAP ACI based on our extended user class? Say let the 
IPA server load our custom.py which extends "user" with 
"mailroutingaddress" attribute and then call "ipa whatever" which 
effectively modifies FreeIPA's notion of user class and redefines the ACI?


Kind regards,

--
Petr Fišer

BCV solutions s.r.o.
Mobile: +420 607 618 243
E-mail:petr.fi...@bcvsolutions.eu
Jabber:petr.fi...@bcvsolutions.eu


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

[Freeipa-users] custom attributes as a part of default ipa permissions

[Petr Fišer via FreeIPA-users]

Hello,
We are currently deploying FreeIPA and we make use of custom attributes.
We defined them in custom.py script (located in 
/usr/lib/python2.7/site-packages/ipaserver/plugins/custom.py). custom.py 
looks like this:


from ipaserver.plugins.user import user
from ipalib.parameters import Int
from ipalib.parameters import Str
from ipalib import _
user.user.takes_params = user.user.takes_params + (
Str('mailroutingaddress?',
cli_name='mailroutingaddress'
label=_('Mail routing address'),)
)

This works fine, server makes the attribute visible through API and also 
the "ipa" command can work with it. Basically, we made those attributes 
part of our default.
However, users (ordinary user in FreeIPA and also sysaccounts) cannot 
access those attributes when binding directly to the LDAP. This is due 
to ACI that FreeIPA writes into the LDAP.


I know that in FreeIPA:

 * For user himself, ldap://self filter can be defined with "ipa
   selfservice-add 'some name' --attrs=mailroutingaddress
   --permissions=read" .
 * For user to read attributes of other users, I can define permission,
   privilege and role and add this role to a user or group.
 * For sysaccounts, it is advised to define custom ACI in the LDAP itself.

What I am thinking of: Is there any way that I can make FreeIPA 
re-generate its LDAP ACI based on our extended user class? Say let the 
IPA server load our custom.py which extends "user" with 
"mailroutingaddress" attribute and then call "ipa whatever" which 
effectively modifies FreeIPA's notion of user class and redefines the ACI?


Kind regards,

--
Petr Fišer

BCV solutions s.r.o.
Mobile: +420 607 618 243
E-mail: petr.fi...@bcvsolutions.eu
Jabber: petr.fi...@bcvsolutions.eu

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

[Freeipa-users] Re: IPA replica with CA role problems

[Mark Haney via FreeIPA-users]

On 08/02/2017 04:17 PM, Fraser Tweedale wrote:



- /var/log/ipareplica-install.log from replica
- /etc/pki/pki-tomcat/ca/debug from both master and replica

Those logs should do for a start.

I'd also like to see your /etc/pki/pki-tomcat/ca/CS.cfg from both
master and replica.  Depending on where investigation goes I might
ask for some LDAP entries too, but I'm not up to that point yet.

Feel free to send logs directly to me and/or redact them as you see
fit.


Oh, and which version of IPA are you creating the replica from?

Thanks,
Fraser


Actually that won't be necessary, it took two of us looking at it, but 
we figured out the problem.  Based on what I can gather, when IPA0 was 
built, kinit admin wasn't run prior to updating the GoDaddy certs.  (The 
documentation isn't real clear on that, if said documentation was 
perused while setting it up.  As I said, I didn't build the server.)  
Once the GD cert files were pulled from nssdb on IPA0 and reinstalled 
and updated with kinit admin ipa-certupdate, it seems to have cleared up 
the wonky configuration on that side.


Then, we went the nuclear option and removed the ipa-server packages 
from IPA1, re-installed them, ran ipa-client-install (which I didn't run 
and wasn't clear that it needed to be run), then run the 
ipa-replica-install --setup-ca and now everything is kosher.


I was fairly certain as I got into debugging it that it wasn't a bug, as 
the documentation tells you different things depending on what 
documentation you look at (ie, RH vs FreeIPA docs), so wasn't sure where 
the issue lie.   Most of the time, I had focused on something not right 
with IPA1, not really considering IPA0 could be jacked up in its own 
special way.  It was my colleague who reminded me there were two parts 
to the equation.  Tunnel vision still gets me even after 20 years of 
doing this!


Now though, we're up and running fine and ready to being a real rollout 
to our production servers.


I appreciate all the help from the list.

--
Mark Haney
Network Engineer at NeoNova
919-460-3330 option 1
mark.ha...@neonova.net
www.neonova.net

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

[Freeipa-users] PKI debug files are not rotated

[Harald Dunkel via FreeIPA-users]

Hi folks,

I found some very large log files in 

/var/log/pki/pki-tomcat/ca

On the major CA host the "debug" file is >1GByte and was never 
rotated. It seems that there is a responsible config file /etc/\
pki/pki-tomcat/ca/CS.cfg, setting

debug.append=true
debug.enabled=true
debug.filename=/var/lib/pki/pki-tomcat/logs/ca/debug
debug.hashkeytypes=
debug.level=0
debug.showcaller=false

Maybe I am too blind to see, but I haven't found an appropriate
menu in the web interface to alter these settings. Is it safe to 
edit this file on the command line, bypassing the ipa web or 
command line interfaces? How can I enable log file rotation?

This is Freeipa 4.4.0 on Centos 7.3.


Every helpful comment is highly appreciated
Harri
-- 
aixigo AG, Karl-Friedrich-Strasse 68, 52072 Aachen, Germany
phone: +49 241 559709-79, fax: +49 241 559709-99
eMail: harald.dun...@aixigo.de, web: http://www.aixigo.de
Amtsgericht Aachen - HRB 8057, Vorstand: Erich Borsch, Christian Friedrich, 
Tobias Haustein, Vors. des Aufsichtsrates: Prof. Dr. Ruediger von Nitzsch
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Edit named-pkcs11

[Florence Blanc-Renaud via FreeIPA-users]

On 08/03/2017 02:10 AM, Tejas Desai via FreeIPA-users wrote:
BIND uses the directives “type forward” and “forward first” in its 
named.conf file. How can I make use of BIND directives when using ipa 
dns? Because it is based on BIND, can I edit named-pkcs11 directly? Tejas




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


Hi,

When using IPA DNS, you should always use ipa tools to manage the DNS 
configuration. For more information, please see the chapter Managing DNS 
in Linux  Domain Identity, Authentication and Policy Guide [1].


There is for instance a description of supported DNS zone types [2] 
(master, forward) and a chapter Managing DNS forwarding [3].


Flo

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Working_with_DNS.html


[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/supported-dns-zone-types.html


[3] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-dns-forwarding.html

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

[Freeipa-users] Re: Failed Upgrade?

[Florence Blanc-Renaud via FreeIPA-users]

On 08/02/2017 11:51 PM, Ian Harding via FreeIPA-users wrote:

On 08/02/2017 12:11 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 01:43 AM, Ian Harding wrote:

On 08/01/2017 12:03 PM, Rob Crittenden wrote:

Ian Harding wrote:

On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 03:11 PM, Ian Harding wrote:

On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:



On 07/31/2017 11:34 AM, Rob Crittenden wrote:

Ian Harding via FreeIPA-users wrote:
I had an unexpected restart of an IPA server that had 
apparently had

updates run but had not been restarted.  ipactl says pki-tomcatd
would
not start.

Strangely, the actual service appears to be running:



dogtag is an application within tomcat so tomcat can run without
dogtag
running.

We need to see more of the dogtag debug log to see what is 
going on.




It looks like an authentication problem...

[28/Jul/2017:10:08:47][localhost-startStop-1]: SSL handshake 
happened
Could not connect to LDAP server host seattlenfs.bpt.rocks port 
636

Error netscape.ldap.LDAPException: Authentication failed (49)



Hi,

dogtag stores its internal data in the LDAP server and needs to
establish a secure LDAP connection. You can check how this
connection is configured in /etc/pki/pki-tomcat/ca/CS.cfg, look for
the lines:

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=cn=Directory Manager
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
internaldb.ldapconn.host=vm-...
internaldb.ldapconn.port=636
internaldb.ldapconn.secureConn

authtype can be SslClientAuth (authentication with a ssl
certificate) or BasicAuth (authentication with a bind DN and
password stored in /var/lib/pki/pki-tomcat/conf/password.conf).

You can use this information to manually check the credentials. For
instance with sslclientauth:

export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
export LDAPTLS_CERT='subsystemCert cert-pki-ca'

ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
(provide the password from /etc/pki/pki-tomcat/alias/pwdfile.txt)



I found this:

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
internaldb.ldapconn.cloneReplicationPort=389
...

and when I try the ldapsearch I am presented with a prompt to 
provide

a pin/password

Please enter pin, password, or pass phrase for security token 
'ldap(0)':


but there is no password file...


Hi,

you are right, in 4.4. there is no pwdfile.txt and the password 
can be

found in /var/lib/pki/pki-tomcat/conf/password.conf (with the tag
internal=...)

Can you check if the password with the tag internal=... allows to 
read

the keys from the NSS db?
certutil -K -d /etc/pki/pki-tomcat/alias
(provide password)


That works...

# certutil -K -d /etc/pki/pki-tomcat/alias
certutil: Checking token "NSS Certificate DB" in slot "NSS User 
Private

Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa  0f327e760a7eecdcf6973f5dc57ca5367c592d64   (orphan)
< 1> rsa  b12580c7c696cfcd8aefc9405a7a870b24b7b96a   NSS 
Certificate

DB:auditSigningCert cert-pki-ca
< 2> rsa  881b7254c40fa40bc50681bcc8d37bb3eb49937e   caSigningCert
cert-pki-ca
< 3> rsa  fa9a255a1d15585ac28064c0f4986e416bc48403   NSS 
Certificate

DB:ocspSigningCert cert-pki-ca
< 4> rsa  3fb609d0f7d72c2d325d6a2dc16577a7f7e5a01f   Server-Cert
cert-pki-ca
< 5> rsa  1e9479a9556af9339bb5e4552ccbd381d3c38856   NSS 
Certificate

DB:subsystemCert cert-pki-ca

But this doesn't (with the same password from password.conf)

# ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
Please enter pin, password, or pass phrase for security token 
'ldap(0)':

SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)

That password is getting me somewhere though, since if I put in a
nonsense or incorrect password it just prompts over and over.


Let's step back a second. You upgraded from what to what?


There wasn't much of a change... I just assumed someone ran yum 
upgrade and didn't restart, then the power outage... it looks like 
not much of a version change though.


# grep ipa /var/log/yum.log
Jan 08 04:45:32 Installed: ipa-common-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:45:32 Installed: 
ipa-client-common-4.4.0-14.el7.centos.1.1.noarch

Jan 08 04:46:06 Updated: libipa_hbac-1.14.0-43.el7_3.4.x86_64
Jan 08 04:46:07 Updated: python-libipa_hbac-1.14.0-43.el7_3.4.x86_64
Jan 08 04:46:08 Installed: python-ipaddress-1.0.16-2.el7.noarch
Jan 08 04:47:04 Installed: python2-ipalib-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:47:05 Installed: 
python2-ipaclient-4.4.0-14.el7.centos.1.1.noarch

Jan 08 04:47:05 Updated: ipa-admintools-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:47:05 Installed: 

[Freeipa-users] Re: ipa-getcert and java certstore/keytool

[Jochen Kellner via FreeIPA-users]

Hi,

3. August 2017 03:03, "Fraser Tweedale via FreeIPA-users" 

schrieb:

> On Wed, Aug 02, 2017 at 11:11:09PM +0200, Jochen Hein via FreeIPA-users wrote:
>> I'm playing around with keycloak and wanted to use an SSL certificate
>> from IPA. I've looked around but didn't see any howto about using java
>> keytool with ipa-getcert. Has someone experience with it?
>> 
> Might as well jump straight to commands/logs :)

I did some more research yesterday and finally got a certificate
along the following lines:

- Generate a java keystore with keytool as described in the keycloak docs.
- Generate a csr with keytool and paste it into Freeipa.
- Got a certificate back from Freeipa.
- Import the certificate into keytool (again keycloak docs).

My first tries had the cert attributes wrong, but I think I now got it right,
but need to check with chrome to be sure. I'll post my steps later.

I was not successful in creating a certificate with ipa-getcert and
import the key into keytool. But I'll try to get something monitored by
certmonger - otherwise I'm sure the cert would expire... 

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

[Freeipa-users] Re: AD trust setup woes

[Alexander Bokovoy via FreeIPA-users]

On to, 03 elo 2017, Igor Sever via FreeIPA-users wrote:

I didn’t specify any ID range. This was all done automagically by
setup. I read a lot of documentation, and I can’t remember that ever
been mentioned. We indeed had NIS at some point, but this is not
supported any more by MS, and FreeIPA should not just presume that we
have gidNumber on all accounts. Where should I look for settings that
you specify?

For a succinct answer look at what Justin wrote you yesterday.

Documentation is available here:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#id-ranges

You have all the options to either go with automated detection or
override which ID range type to use.

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