Re: [Freeipa-users] ID Mapping

[Jakub Hrozek]

On Sun, Feb 26, 2017 at 12:12:23PM -0800, Hanoz Elavia wrote:
> Hey guys,
> 
> Is it possible to disable ID mapping for AD users in a FreeIPA AD trust
> setup?
> 
> The version report is as follows:
> 
> AD: Windows 2008 R2
> FreeIPA Server: 4.4.0-14
> FreeIPA Client: 4.4.0-14
> SSSD: 1.14.0-43
> Linux version: CentOS 7.3 x64_86
> 
> I've tried setting ldap_id_mapping = False in sssd.conf in the IPA domain
> sectionwith no success.
> 
> Regards,
> 
> Hanoz

In IPA-AD trust environment the mapping is managed on the server. So
you'd need to remove the algorithmical range and add a POSIX range
instead (see  ipa help idrange-add, --type=['ipa-ad-trust-posix',
'ipa-ad-trust', 'ipa-local'])

Note that clients cannot modify the range type at the moment, so you
also need to remove the cache from all clients in the domain.

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

[Freeipa-users] ID Mapping

[Hanoz Elavia]

Hey guys,

Is it possible to disable ID mapping for AD users in a FreeIPA AD trust
setup?

The version report is as follows:

AD: Windows 2008 R2
FreeIPA Server: 4.4.0-14
FreeIPA Client: 4.4.0-14
SSSD: 1.14.0-43
Linux version: CentOS 7.3 x64_86

I've tried setting ldap_id_mapping = False in sssd.conf in the IPA domain
sectionwith no success.

Regards,

Hanoz
-- 
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] authenticating with dns

[Aaron Young]

learned some things in the last few days

I believe one of the root problems I have, if not THE root problem, is that
I cannot start pki-tomcatd on my nyc01ipa02 machine. I now believe that if
I could get that machine to work correctly, I could get all the others

So, I get this in my logs

from /var/log/pki/pki-tomcat/ca/debug

> LdapJssSSLSocket: set client auth cert nickname subsystemCert cert-pki-ca
> SSLClientCertificatSelectionCB: Entering!
> Candidate cert: subsystemCert cert-pki-ca
> SSLClientCertificateSelectionCB: desired cert found in list: subsystemCert
> cert-pki-ca
> SSLClientCertificateSelectionCB: returning: subsystemCert cert-pki-ca
> SSL handshake happened
> Could not connect to LDAP server host nyc01ipa02.mf port 636 Error
> netscape.ldap.LDAPException: Authentication failed (49)



from /var/log/dirsrv/slapd-MF/errors

> slapi_search_internal ("o=ipaca", subtree, seeAlso=CN=CA Subsystem,O=MF)
> err 32



which makes me think that the problem is the CA Subsystem secret isn't
available

when I do a "getcert list" I see that there are 8 keys

certificate: 'auditSigningCert
certificate: 'ocspSigningCert
certificate: 'subsystemCert
certificate: 'caSigningCert
certificate: 'ipaCert'
certificate: 'Server-Cert
certificate: 'Server-Cert'
certificate: 'Server-Cert'

should there be others?

also, I found this link
https://fedorahosted.org/freeipa/ticket/5100#comment:9
and this person outlined the a number of steps (I included them below) and
they seem reasonable to fix a problem like I'm experiencing...however, I
don't know how to do step 1. If anyone knows how to do that...?


   1. Make changes to cause FreeIPA to think it is CA-less.


   1. Extract CA signing key from a replica info file.


   1. Run ipa-ca-install to install the CA on one of the IPA servers, with
   external CA. This will generate a new private key and CSR to send to
   external CA.


   1. Replace the new private key generated for the CSR, with the private
   key from the replica info file.


   1. Continue the ipa-ca-install with the CA signing certificate from the
   replica info file.


   1. Manually adjust serial number ranges to ensure the new CA instance
   does not issue certs with serial numbers that collide with certs issued by
   the original CA instance. (This might have to be hacked into the
   ipa-ca-install process).


   1. Depending on whether your CA is self-signed, might need to tell
   certmonger to track the CA signing certificate.






On Thu, Feb 23, 2017 at 11:57 AM, Aaron Young 
wrote:

> And yes, I learned to stop using kadmin after I made that note
>
> On Thu, Feb 23, 2017 at 11:56 AM, Aaron Young 
> wrote:
>
>> on ld4ipa01, I removed it with ipa-server-install --uninstall
>>
>> this was an attempt to recreate the replica from nyc02ipa02
>>
>> On Thu, Feb 23, 2017 at 3:17 AM, Martin Basti  wrote:
>>
>>>
>>>
>>> On 22.02.2017 23:26, Aaron Young wrote:
>>>
>>> Hello Everyone
>>>
>>> I recently lost the master master IPA server setup by the previous
>>> administrator.
>>> As it stands now, if I try to add a new client, in order to standup a
>>> new replica, I get errors while trying to setup DNS. This led me to look at
>>> how authentication worked (I'm new to IPA) and I learned about the kerberos
>>> tools
>>>
>>> I don't know if I'm familiar enough with the terminology to adequately
>>> describe what I'm experiencing, so I'll give you some of the commands and
>>> their results
>>>
>>> but first, a bit on the design
>>>
>>> before I got to this, we had
>>>
>>> a <-> b <-> c <-> d
>>>
>>> b was the master master
>>>
>>> a, happened to point to two test servers nyc02ipa01 and nyc02ipa02 (not
>>> pictured, I discovered them later when c and d started having problems)
>>>
>>> a - nyc01ipa02
>>> b - nyc01ipa01
>>> c - ld4ipa01
>>> d - ld4ipa02
>>>
>>> currently, I have nyc02ipa02 <-> nyc01ipa02
>>>
>>> the reason I have it limited like this is because all the other servers
>>> stopped replicating for one reason or another (mainly that they can't
>>> authenticate or in one case, there was a database record corruption)
>>>
>>> Anyway, here are some activities and logs from the latest round of fixes
>>> and information activities I've been engaging in
>>>
>>> 22:54:32 root@nyc01ipa02:~# kinit admin
>>> kinit: Clients credentials have been revoked while getting initial
>>> credentials
>>>
>>> Reading through this
>>>  tells me
>>> that
>>>
>>> # kadmin: modprinc -unlock PRINCNAME
>>>
>>> will unlock an account...but if I can't get in
>>>
>>> 22:54:37 root@nyc01ipa02:~# kadmin
>>> Authenticating as principal root/admin@MF with password.
>>> kadmin: Client 'root/admin@MF' not found in Kerberos database while
>>> initializing kadmin interface
>>>
>>> on ld4ipa02, did a
>>>
>>> # ipa-client-install --uninstall
>>>
>>> then
>>>
>>> # ipa-client-install --force-join 

Re: [Freeipa-users] CentOS 6 -> 7 migration

[Rob Verduijn]

Sounds feasable, however I'm not sure which solution entails the most work.

In step 3 you loose all the extra functionalities( cups/squid/ntp ) as
well, while these stay preserved by a p2v including a nice backup.
You do need a backup of all the functions before proceeding with step3.

Rob Verduijn

2017-02-26 14:40 GMT+01:00 Ian Pilcher :

> On 02/26/2017 05:08 AM, Rob Verduijn wrote:
>
>> You should consider setting up a temporary vm to migrate from.
>> On one of your client systems, I assume you got at least 1 ipa client
>>
>> Try looking at http://libguestfs.org/virt-p2v.1.html to migrate your
>> current system to a vm  (side effect : instant full backup)
>>
>> When you got the vm up and running you can reinstall your main system
>> with the new os and ipa.
>> Then replicate the old ipa to the new one.
>>
>
> Hmm.  The system that runs IPA is the "network server" in my home
> network.  It runs various services -- DNS, NTP, CUPS, squid, etc. -- as
> well as routing between various VLANs.  So simply P2V'ing it would be
> a major project in its own right.
>
> What about this, though ...
>
> 1.  Set up a new CentOS 7 VM running IPA
>
> 2.  Replicate the IPA data from the old CentOS 6 system to the VM.
>
> 3.  Install CentOS 7 on the original system
>
> 4.  Replicate the IPA data back from the VM
>
> Will this work?
>
> --
> 
> Ian Pilcher arequip...@gmail.com
>  "I grew up before Mark Zuckerberg invented friendship" 
> 
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] CentOS 6 -> 7 migration

[Ian Pilcher]

On 02/26/2017 05:08 AM, Rob Verduijn wrote:

You should consider setting up a temporary vm to migrate from.
On one of your client systems, I assume you got at least 1 ipa client

Try looking at http://libguestfs.org/virt-p2v.1.html to migrate your
current system to a vm  (side effect : instant full backup)

When you got the vm up and running you can reinstall your main system
with the new os and ipa.
Then replicate the old ipa to the new one.


Hmm.  The system that runs IPA is the "network server" in my home
network.  It runs various services -- DNS, NTP, CUPS, squid, etc. -- as
well as routing between various VLANs.  So simply P2V'ing it would be
a major project in its own right.

What about this, though ...

1.  Set up a new CentOS 7 VM running IPA

2.  Replicate the IPA data from the old CentOS 6 system to the VM.

3.  Install CentOS 7 on the original system

4.  Replicate the IPA data back from the VM

Will this work?

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


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

[Rob Verduijn]

Upgrading centos6 to 7 is not a smart thing, unless you like to suffer a
lot of issues.

Then there are many comaptibility issues regarding the upgrade from ipa3.3
to 4.4

You should consider setting up a temporary vm to migrate from.
On one of your client systems, I assume you got at least 1 ipa client

Try looking at http://libguestfs.org/virt-p2v.1.html to migrate your
current system to a vm  (side effect : instant full backup)

When you got the vm up and running you can reinstall your main system with
the new os and ipa.
Then replicate the old ipa to the new one.

Rob Verduijn



2017-02-26 0:45 GMT+01:00 Ian Pilcher :

> Is there any way to migrate an IPA server from 6 -> 7 without losing all
> of the IPA configuration and data?  All of the documentation I can find
> involves setting up a replica, replicating the data over, and then
> decommissioning the old system; not exactly an option with a single
> system.
>
> --
> 
> Ian Pilcher arequip...@gmail.com
>  "I grew up before Mark Zuckerberg invented friendship" 
> 
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] unable to decode: {replica

[lejeczek]

hi everyone

I first time see:

unable to decode: {replica 60} 586eaffd000a003c 
586eaffd000a003c

Replica Update Vectors:


on all four servers. What would be a correct troubleshooting 
and fixing this problem?

many thanks,
L.
-- 
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