[Freeipa-users] Re: Question regarding filtering of users seen by managing users

[Thomas Handler via FreeIPA-users]

Hi Rob,

thank you for this clarification, it’s highly appreciated.

Best regards,

Tom




From: Rob Crittenden via FreeIPA-users 
Reply: FreeIPA users list 
Date: 19 July 2017 at 20:57:18
To: FreeIPA users list 
Cc: Thomas Handler , Rob Crittenden 
Subject:  [Freeipa-users] Re: Question regarding filtering of users seen by 
managing users  

Thomas Handler via FreeIPA-users wrote:  
> Dear all,  
>  
> I have installed FreeIPA and try to learn about the concepts.  
>  
> I’ve been looking around, reading documents that I found and searched  
> but did not find any useful hints how to configure FreeIPA to solve my  
> problem I describe below.  
>  
> Any hints will be greatly appreciated!  
>  
> I’m looking for a solution of the following:  
>  
> Given an organizationm let’s call it IT-Company. This organization has a  
> couple of administrators which are repsonsible for maintaining users and  
> hosts of the organization on FreeIPA. But IT-Company also has customers  
> for whom it hosts some machines and some user accounts.  
>  
> Each of these customers should be able to manage their own users but  
> they should not see users and hosts outside their scope.  
>  
> I found messages explaining the restrictions that inhibit users  
> managing/changing anything outside their scope but I did not find  
> anything showing how to filter the users/hosts shown to them.  
>  
> Can this be done with FreeIPA and if so how?  
>  

IPA doesn't support multi-tenancy so no, this isn't possible.  

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: Preserved IPA users got deleted from AD

[Rob Brown via FreeIPA-users]

Well, I certainly don't understand what happened under the covers, but is
100% clear to me that the users got "deleted" in AD while "preserving" them
in IPA.
I could see an argument where "ipa user-del user --preserve" is technically
still a delete (semantics).

I might look at migrating to a trust in the future, but now this is a
caveat to live with.
I still might explore one-way sync in the meantime, see what that buys us.

On Thu, Jul 20, 2017 at 2:45 PM, Rob Crittenden  wrote:

> Rob Brown wrote:
> > yeah, I did find the users in AD under:
> > CN=Deleted Objects,DC=foo,DC=domain,DC=com
> > and, the users actually have the attribute:
> > isDeleted = TRUE
> > so, looks like they were actually deleted (from AD perspective).
> > It seems like the delete sync is two-way (surprising, since create
> > isn't), and this is probably expected, and that IPA simply exposes the
> > deleted users via the GUI in "Preserved Users", whereas AD doesn't.
> > Still, this kinda took me by surprise, lesson learned. Seems I can
> > recover deleted accounts, but going to be a PITA.
> > Looking thru the docs, I don't see any options to disable deletes. It
> > would be nice to have an option similar to how ipaWinSyncAcctDisable
> > works, but for deletes, so we could set it to one-way.
> > I am wondering if setting the oneWaySync parameter on the
> > synchronization agreement to 'fromWindows' would do the trick. Not sure
> > I really want that, though, will have to think it thru.
>
> Re-adding list...
>
> The delete sync isn't two-way since the user wasn't deleted on the IPA
> side, just moved.
>
> The IPA team isn't devoting much, if any time, these days on winsync,
> instead focusing on AD trust. Given the complexity of trying to find an
> equivalent state in AD of kinda-deleted and implementing, test, etc I
> doubt this is something that will be addressed.
>
> Probably worth documenting as an undesirable side-effect though.
>
> rob
>
> >
> > On Thu, Jul 20, 2017 at 11:55 AM, Rob Crittenden  > > wrote:
> >
> > Rob Brown via FreeIPA-users wrote:
> > > Our company recently implemented freeipa to replace a cent5
> kerberos
> > > infrastructure. We set it up with a Winsync agreement with an AD
> > domain,
> > > and is working pretty well.
> > > Our user disposition workflow in AD is this: user account is
> disabled,
> > > and moved to a "terminated users" OU in AD. The account disable
> > sync was
> > > working fine to IPA, but yesterday I decided to "clean up" the
> Active
> > > Users list in IPA, by deleting (with --preserve) all the disabled
> > > accounts (there were many). This looked fine from the IPA side: the
> > > accounts got moved into the Preserved users area (in the gui).
> > > However, much to my dismay I later discovered that all of the
> termed
> > > accounts in AD are gone. WHAT!!!???
> > > This is bad (for historical/compliance), and came as a shock to me,
> > > because the docs say: "While modifications are bi-directional
> (going
> > > both from Active Directory to IdM and from IdM to Active
> Directory),
> > > creating or adding accounts are only uni-directional, from Active
> > > Directory to Identity Management". So WHY ON EARTH would a delete
> be
> > > bi-directional? I'm suspecting (hoping) that the accounts weren't
> > > actually deleted, that they are just hidden somewhere in AD that I
> > can't
> > > see. PLEASE, if anyone can point me in the right direction here as
> to
> > > what happened I would appreciate it.
> >
> > As someone mentioned in IRC marking a user as preserved moves them
> from
> > the user container to cn=deleted
> > users,cn=accounts,cn=provisioning,$SUFFIX.
> >
> > So perhaps AD honored the rename.
> >
> > 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: Preserved IPA users got deleted from AD

[Rob Crittenden via FreeIPA-users]

Rob Brown wrote:
> yeah, I did find the users in AD under:
> CN=Deleted Objects,DC=foo,DC=domain,DC=com
> and, the users actually have the attribute:
> isDeleted = TRUE
> so, looks like they were actually deleted (from AD perspective).
> It seems like the delete sync is two-way (surprising, since create
> isn't), and this is probably expected, and that IPA simply exposes the
> deleted users via the GUI in "Preserved Users", whereas AD doesn't.
> Still, this kinda took me by surprise, lesson learned. Seems I can
> recover deleted accounts, but going to be a PITA.
> Looking thru the docs, I don't see any options to disable deletes. It
> would be nice to have an option similar to how ipaWinSyncAcctDisable
> works, but for deletes, so we could set it to one-way.
> I am wondering if setting the oneWaySync parameter on the
> synchronization agreement to 'fromWindows' would do the trick. Not sure
> I really want that, though, will have to think it thru.

Re-adding list...

The delete sync isn't two-way since the user wasn't deleted on the IPA
side, just moved.

The IPA team isn't devoting much, if any time, these days on winsync,
instead focusing on AD trust. Given the complexity of trying to find an
equivalent state in AD of kinda-deleted and implementing, test, etc I
doubt this is something that will be addressed.

Probably worth documenting as an undesirable side-effect though.

rob

> 
> On Thu, Jul 20, 2017 at 11:55 AM, Rob Crittenden  > wrote:
> 
> Rob Brown via FreeIPA-users wrote:
> > Our company recently implemented freeipa to replace a cent5 kerberos
> > infrastructure. We set it up with a Winsync agreement with an AD
> domain,
> > and is working pretty well.
> > Our user disposition workflow in AD is this: user account is disabled,
> > and moved to a "terminated users" OU in AD. The account disable
> sync was
> > working fine to IPA, but yesterday I decided to "clean up" the Active
> > Users list in IPA, by deleting (with --preserve) all the disabled
> > accounts (there were many). This looked fine from the IPA side: the
> > accounts got moved into the Preserved users area (in the gui).
> > However, much to my dismay I later discovered that all of the termed
> > accounts in AD are gone. WHAT!!!???
> > This is bad (for historical/compliance), and came as a shock to me,
> > because the docs say: "While modifications are bi-directional (going
> > both from Active Directory to IdM and from IdM to Active Directory),
> > creating or adding accounts are only uni-directional, from Active
> > Directory to Identity Management". So WHY ON EARTH would a delete be
> > bi-directional? I'm suspecting (hoping) that the accounts weren't
> > actually deleted, that they are just hidden somewhere in AD that I
> can't
> > see. PLEASE, if anyone can point me in the right direction here as to
> > what happened I would appreciate it.
> 
> As someone mentioned in IRC marking a user as preserved moves them from
> the user container to cn=deleted
> users,cn=accounts,cn=provisioning,$SUFFIX.
> 
> So perhaps AD honored the rename.
> 
> 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: Two way trust problem

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 20, 2017 at 12:20:31PM -0400, Steve Weeks via FreeIPA-users wrote:
> We've setup a two-way trust with AD and it seems to have worked, but it
> doesn't look like it is working correctly.
> 
> The kerberos commands (kinit and kvno) work fine, but things like 'id
> adu...@addomain.example.com' and 'getent passwd adu...@addomain.example.com'
> don't work.
> 
> # ipa trust-add --type ad addomain.example.com --admin adadmin --password
> --two-way=true
> Active Directory domain administrator's password:
> -
> Added Active Directory trust for realm "addomain.example.com"
> -
>   Realm name: addomain.example.com
>   Domain NetBIOS name: ADDOMAIN
>   Domain Security Identifier: S-1-5-21-2229161606-873856335-779138662
>   Trust direction: Two-way trust
>   Trust type: Active Directory domain
>   Trust status: Established and verified
> 
> # kinit adu...@addomain.example.com
> Password for adu...@addomain.example.com:
> 
> # klist
> Ticket cache: KEYRING:persistent:0:krb_ccache_o3D2R5S
> Default principal: adu...@addomain.example.com
> 
> Valid starting   Expires  Service principal
> 07/20/2017 12:16:41  07/20/2017 22:16:41  krbtgt/
> addomain.example@addomain.example.com
> renew until 07/21/2017 12:16:38
> 
> # id adu...@addomain.example.com
> id: ‘adu...@addomain.example.com’: no such user
> 
> Is this the best way to test the trust?
> 
> We are running FreeIPA 4.4 and Windows Server 2012 R2
> 
> When setting up the trust we needed to modify /etc/hosts as described in
> https://bugzilla.redhat.com/show_bug.cgi?id=878168

Since the trust is two-way, can you kinit using the system keytab and
try searching the AD DC? e.g.

kinit -k
ldapsearch -Y GSSAPI -H ldap://your.ad.dc -s base -b ""

that should return the rootDSE and give you the ldap/your.ad.dc ticket
in the process if the trust works OK..
___
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-client-install generates bad sssd.conf

[Jakub Hrozek via FreeIPA-users]

On Thu, Jul 20, 2017 at 02:33:50PM +0200, John Keates via FreeIPA-users wrote:
> Hi,
> 
> Using SSSD 1.15.2-1 and FreeIPA Client 4.4.4-1 on Debian Stretch 9.0 
> generates a broken SSSD configuration.
> Adding the services manually to sssd.conf fixes this:
> 
> services = nss, sudo, pam, ssh
> 
> For some reason, ipa-client-install thinks we have socket-activated SSSD 
> services, but we don’t. From the SSSD package, we only get:
> 
> - sssd.service
> - sssd-secrets.socket
> - sssd-secrets.service
> 
> There seems to be a mismatch between what gets configured in sssd.conf and 
> what is actually on the system.
> I should probably report it as a bug against the Debian package, but I wonder 
> where the assumption for SSSD.conf is made. It is definitely generated by 
> ipa-client-install, but maybe it’s because it sees the socket-activated SSSD 
> components as a requirement?

There was a thread on Mar 3rd titled "ipa-client-install generates bad
sssd.conf", you might want to check it out although I didn't see any
conclusion in the thread..
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Preserved IPA users got deleted from AD

[Rob Crittenden via FreeIPA-users]

Rob Brown via FreeIPA-users wrote:
> Our company recently implemented freeipa to replace a cent5 kerberos
> infrastructure. We set it up with a Winsync agreement with an AD domain,
> and is working pretty well.
> Our user disposition workflow in AD is this: user account is disabled,
> and moved to a "terminated users" OU in AD. The account disable sync was
> working fine to IPA, but yesterday I decided to "clean up" the Active
> Users list in IPA, by deleting (with --preserve) all the disabled
> accounts (there were many). This looked fine from the IPA side: the
> accounts got moved into the Preserved users area (in the gui).
> However, much to my dismay I later discovered that all of the termed
> accounts in AD are gone. WHAT!!!???
> This is bad (for historical/compliance), and came as a shock to me,
> because the docs say: "While modifications are bi-directional (going
> both from Active Directory to IdM and from IdM to Active Directory),
> creating or adding accounts are only uni-directional, from Active
> Directory to Identity Management". So WHY ON EARTH would a delete be
> bi-directional? I'm suspecting (hoping) that the accounts weren't
> actually deleted, that they are just hidden somewhere in AD that I can't
> see. PLEASE, if anyone can point me in the right direction here as to
> what happened I would appreciate it.

As someone mentioned in IRC marking a user as preserved moves them from
the user container to cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX.

So perhaps AD honored the rename.

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

[Freeipa-users] Preserved IPA users got deleted from AD

[Rob Brown via FreeIPA-users]

Our company recently implemented freeipa to replace a cent5 kerberos
infrastructure. We set it up with a Winsync agreement with an AD domain,
and is working pretty well.
Our user disposition workflow in AD is this: user account is disabled, and
moved to a "terminated users" OU in AD. The account disable sync was
working fine to IPA, but yesterday I decided to "clean up" the Active Users
list in IPA, by deleting (with --preserve) all the disabled accounts (there
were many). This looked fine from the IPA side: the accounts got moved into
the Preserved users area (in the gui).
However, much to my dismay I later discovered that all of the termed
accounts in AD are gone. WHAT!!!???
This is bad (for historical/compliance), and came as a shock to me, because
the docs say: "While modifications are bi-directional (going both from
Active Directory to IdM and from IdM to Active Directory), creating or
adding accounts are only uni-directional, from Active Directory to Identity
Management". So WHY ON EARTH would a delete be bi-directional? I'm
suspecting (hoping) that the accounts weren't actually deleted, that they
are just hidden somewhere in AD that I can't see. PLEASE, if anyone can
point me in the right direction here as to what happened I would appreciate
it.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: different failed auth times?

[Rob Crittenden via FreeIPA-users]

Vince Mele via FreeIPA-users wrote:
> On Thu, Jul 20, 2017 at 10:41 AM, Rob Crittenden via FreeIPA-users
>  > wrote:
> 
> Kat via FreeIPA-users wrote:
> > Hi,
> >
> > If I have a simple pair of FreeIPA servers and one is showing different
> > failed auth times for a user -- is this a good indication they are out
> > of sync? Should I not see same failures on both?
> 
> The lockout attributes are per-server (not replicated).
> 
> rob
> 
> 
> Is there a way to turn this on globally? I've seen FreeIPA proposals
> that go back years regarding a global lockout attribute that could be
> replicated. I've also seen the 389 config setting passwordIsGlobalPolicy.
> 
> I am personally less concerned about amplifying the number of password
> attempts allowed before lockout (e.g., if lockouts are local to each
> replica, then a user can attempt passwordRetryCount x number of
> replicas). My focus is ensuring that if an account is locked out on one
> or more replica(s), that an unlock sent to one replica will push to all
> other replicas. Otherwise, I will have to manually update and check
> every replica every time a user needs their account unlocked. We have a
> burdensome requirement (supposedly) that requires all locked accounts to
> be manually unlocked. 

The issue is that every time a user logs in, or fails to, a replication
event will be triggered. So imagine in the morning as everyone arrives.
Depending on the size of your userbase this could be extensive.

But as I recall the replication agreements are setup with a list of
excluded attributes including the lockout ones: krblastsuccessfulauth,
krblastfailedauth, krbloginfailedcount.

You could modify the nsDS5ReplicatedAttributeList attribute in the
replication agreements and remove those attributes and they should
replicate.

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: different failed auth times?

[Vince Mele via FreeIPA-users]

On Thu, Jul 20, 2017 at 10:41 AM, Rob Crittenden via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Kat via FreeIPA-users wrote:
> > Hi,
> >
> > If I have a simple pair of FreeIPA servers and one is showing different
> > failed auth times for a user -- is this a good indication they are out
> > of sync? Should I not see same failures on both?
>
> The lockout attributes are per-server (not replicated).
>
> rob
>
>
Is there a way to turn this on globally? I've seen FreeIPA proposals that
go back years regarding a global lockout attribute that could be
replicated. I've also seen the 389 config setting passwordIsGlobalPolicy.

I am personally less concerned about amplifying the number of password
attempts allowed before lockout (e.g., if lockouts are local to each
replica, then a user can attempt passwordRetryCount x number of replicas).
My focus is ensuring that if an account is locked out on one or more
replica(s), that an unlock sent to one replica will push to all other
replicas. Otherwise, I will have to manually update and check every replica
every time a user needs their account unlocked. We have a burdensome
requirement (supposedly) that requires all locked accounts to be manually
unlocked.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Two way trust problem

[Steve Weeks via FreeIPA-users]

We've setup a two-way trust with AD and it seems to have worked, but it
doesn't look like it is working correctly.

The kerberos commands (kinit and kvno) work fine, but things like 'id
adu...@addomain.example.com' and 'getent passwd adu...@addomain.example.com'
don't work.

# ipa trust-add --type ad addomain.example.com --admin adadmin --password
--two-way=true
Active Directory domain administrator's password:
-
Added Active Directory trust for realm "addomain.example.com"
-
  Realm name: addomain.example.com
  Domain NetBIOS name: ADDOMAIN
  Domain Security Identifier: S-1-5-21-2229161606-873856335-779138662
  Trust direction: Two-way trust
  Trust type: Active Directory domain
  Trust status: Established and verified

# kinit adu...@addomain.example.com
Password for adu...@addomain.example.com:

# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_o3D2R5S
Default principal: adu...@addomain.example.com

Valid starting   Expires  Service principal
07/20/2017 12:16:41  07/20/2017 22:16:41  krbtgt/
addomain.example@addomain.example.com
renew until 07/21/2017 12:16:38

# id adu...@addomain.example.com
id: ‘adu...@addomain.example.com’: no such user

Is this the best way to test the trust?

We are running FreeIPA 4.4 and Windows Server 2012 R2

When setting up the trust we needed to modify /etc/hosts as described in
https://bugzilla.redhat.com/show_bug.cgi?id=878168

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

[Freeipa-users] Re: different failed auth times?

[Rob Crittenden via FreeIPA-users]

Kat via FreeIPA-users wrote:
> Hi,
> 
> If I have a simple pair of FreeIPA servers and one is showing different
> failed auth times for a user -- is this a good indication they are out
> of sync? Should I not see same failures on both?

The lockout attributes are per-server (not replicated).

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: keys for cert - how to get those?

[Rob Crittenden via FreeIPA-users]

lejeczek via FreeIPA-users wrote:
> 
> 
> On 19/07/17 20:06, Rob Crittenden via FreeIPA-users wrote:
>> lejeczek via FreeIPA-users wrote:
>>> hello fallas
>>>
>>> those certs I see with:
>>> $ ipa cert-find
>>> is it possible to get private key(s) for a given cert? With means of
>>> (any)command line?
>> Not from the CA, no.
>>
>> The CA doesn't store the private keys for the certificates it issues and
>> never sees them at all.
>>
>> You need access to the filesystem containing the private keys to be able
>> to retrieve/extract them.
>>
>> rob
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-le...@lists.fedorahosted.org
> so these are replicas/host certs created during replica/host add that
> I'm looking at - where IPA stores those private keys?
> Would there be any howto on how to get cert+keys pair in standard pem
> out of IPA to use outside of IPA?
>

Depends on what you mean by outside of IPA.

It is a rather terrible idea to share keys between services
security-wise, especially given how easy it is to get a cert from IPA.

That said, it isn't a secret where they are stored. The web cert/key is
in /etc/httpd/alias and the ldap cert/key is in /etc/dirsrv/slapd-REALM

You can use pk12util to export the cert and key as a PKCS#12 file and
then openssl pkcs12 to extract the key from that.


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

[Freeipa-users] different failed auth times?

[Kat via FreeIPA-users]

Hi,

If I have a simple pair of FreeIPA servers and one is showing different 
failed auth times for a user -- is this a good indication they are out 
of sync? Should I not see same failures on both?


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

[Freeipa-users] Re: Replica from RHEL6 7 fails to create CA with clone URI mismatch

[Ade Lee via FreeIPA-users]

On Thu, 2017-07-20 at 01:11 -0400, Endi Sukma Dewata wrote:
> - Original Message -
> > David Hendén via FreeIPA-users wrote:
> > > Hi all,
> > > 
> > > I'm trying to set up a replica from RHEL6.9 FreeIPA 3.0.0 to
> > > RHEL7.3 RHEL
> > > 4.4.0.
> > > 
> > > What I'm trying to achieve is an isolated FreeIPA 4.4 server that
> > > we could
> > > replace the original FreeIPA 3.0 infrastrcuture with. The way I'm
> > > doing
> > > this is:
> > > 
> > >  1) prepare replica file on production ipa01 and copy to ipasync
> > >  2) install replica with CA on ipasync and then remove all
> > > connections to
> > >  ipa01, ipa02 and ipa03 (which is the entire production
> > > infrastructure)
> > >  3) Upgrade schema on ipasync and upgrade to RHEL 6.9 (from RHEL
> > > 6.7)
> > >  4) Prepare replica file on ipasync and copy to ipa01 (a new
> > > clean
> > >  installation in test that should later replace ipa01 in prod)
> > >  5) install replica with CA on ipa01 and then remove all
> > > connections to
> > >  ipasync
> > > 
> > > * Right now I'm failing at the create CA phase in step 5 with:
> > > 
> > >   [2/27]: configuring certificate server instance
> > > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to
> > > configure
> > > CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpDsKVFr'
> > > returned
> > > non-zero exit status 1
> > > 
> > > * I can see that it fails on the subsystem Clone URI in
> > > /var/log/ipareplica-install.log
> > > 
> > > Installation failed:
> > > com.netscape.certsrv.base.BadRequestException: Clone URI does not
> > > match
> > > available subsystems: https://ipasync.xxx.com:443
> > > Please check the CA logs in /var/log/pki/pki-tomcat/ca.
> > > 2017-07-11T15:24:52Z DEBUG stderr=pkispawn: WARNING  ...
> > > unable to
> > > validate security domain user/password through REST interface.
> > > Interface
> > > not available
> > > 
> > > * To get more details I check the debug log for tomcat and find
> > > that it
> > > still tries to match against the old infrastructure and not the
> > > ipasync
> > > server:
> > > 
> > > # cat /var/log/pki/pki-tomcat/ca/debug
> > > ...
> > > [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: len is 3
> > > [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: hostname:
> > > 
> > > [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: admin_port: <443>
> > > [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: hostname:
> > > 
> > > [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: admin_port: <443>
> > > [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: hostname:
> > > 
> > > [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: admin_port: <443>
> > > [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: === Subsystem
> > > Configuration
> > > ===
> > > [11/Jul/2017:17:24:52][http-bio-8443-exec-3]:
> > > SystemConfigService: validate
> > > clone URI: https://ipasync.xxx.com:443
> > > [11/Jul/2017:17:24:52][http-bio-8443-exec-3]: Clone URI does not
> > > match
> > > available subsystems: https://ipasync.xxx.com:443
> > > 
> > > * I validate this by checking the calist in getDomainXML:
> > > 
> > > # wget --no-check-certificate
> > > https://ipasync.xxx.com:443/ca/admin/ca/getDomainXML
> > > # cat getDomainXML | xmllint --format -
> > > ...
> > >   
> > > 
> > >   TRUE
> > >   pki-cad
> > >   FALSE
> > >   80
> > >   443
> > >   443
> > >   443
> > >   443
> > >   ipa01.xxx.com
> > > 
> > > 
> > >   pki-cad
> > >   TRUE
> > >   TRUE
> > >   443
> > >   80
> > >   443
> > >   443
> > >   443
> > >   ipa02.xxx.com
> > > 
> > > 
> > >   pki-cad
> > >   TRUE
> > >   TRUE
> > >   443
> > >   80
> > >   443
> > >   443
> > >   443
> > >   ipa03.xxx.com
> > > 
> > > 3
> > >   
> > > ...
> > > 
> > > Why does it still have the old ipa servers and why is not ipasync
> > > included?
> > > Am I doing something wrong here, for example do I need to
> > > manually add
> > > ipasync to the pki-cad list of CAs?
> > 
> > I don't believe uninstalling an IPA master will update this list as
> > it
> > is maintained by dogtag and other than removing the replication
> > agreements I'm not aware of any other notification that a server is
> > going away.
> > 

Nice detective work!

It seems that the problem here is that ipasync should have been added
to the security domain during the replication in step 2, just as ipa02
and ipa03 were also added during previous replications.

I'm not sure why that did not happen - but it would be useful to get
Dogtag logs for step 2 to try to figure that out.  I recall that in the
past, there was a bug where the Dogtag replication installation code
silently swallowed an exception at the end of the setup, resulting in
the security domain not being updated.  Maybe this is what is happening
here.

To proceed further, you need to manually add the entry for ipasync into
the security domain.  It will look the same as the other entries.  Make
s

[Freeipa-users] ipa-client-install generates bad sssd.conf

[John Keates via FreeIPA-users]

Hi,

Using SSSD 1.15.2-1 and FreeIPA Client 4.4.4-1 on Debian Stretch 9.0 generates 
a broken SSSD configuration.
Adding the services manually to sssd.conf fixes this:

services = nss, sudo, pam, ssh

For some reason, ipa-client-install thinks we have socket-activated SSSD 
services, but we don’t. From the SSSD package, we only get:

- sssd.service
- sssd-secrets.socket
- sssd-secrets.service

There seems to be a mismatch between what gets configured in sssd.conf and what 
is actually on the system.
I should probably report it as a bug against the Debian package, but I wonder 
where the assumption for SSSD.conf is made. It is definitely generated by 
ipa-client-install, but maybe it’s because it sees the socket-activated SSSD 
components as a requirement?

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

[Freeipa-users] Re: keys for cert - how to get those?

[lejeczek via FreeIPA-users]

On 19/07/17 20:06, Rob Crittenden via FreeIPA-users wrote:

lejeczek via FreeIPA-users wrote:

hello fallas

those certs I see with:
$ ipa cert-find
is it possible to get private key(s) for a given cert? With means of
(any)command line?

Not from the CA, no.

The CA doesn't store the private keys for the certificates it issues and
never sees them at all.

You need access to the filesystem containing the private keys to be able
to retrieve/extract them.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
so these are replicas/host certs created during replica/host 
add that I'm looking at - where IPA stores those private keys?
Would there be any howto on how to get cert+keys pair in 
standard pem out of IPA to use outside of IPA?


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