Re: [Freeipa-users] Master Error with two Master CentOS 7.2

[Ludwig Krispenz]

On 01/26/2016 09:45 AM, Günther J. Niederwimmer wrote:

Hello List,

I set up a CentOS 7.2 System with two master Server now I found this 1000 x
Error on my first master?

attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.xxx.at:389/
o%3Dipaca) failed.
did you install and reinstall the replica on the same machine ? The 
message is usually related to removed replicaid, which was not properly 
cleaned.


can you do some searches ?. On both masters check which is the replicaID 
in use and which are the known ruvs:
ldapsearch -b "cn=config"  "objectclass=nsds5replica" replicaid 
nsds50ruv



Ludwig


the second is harmless  I read ;-)
NSMMReplicationPlugin - replication keep alive entry 

Re: [Freeipa-users] How to reference to IPA Server in Multi-Master Setup ?

[Zeal Vora]

Thanks David.

Generally for Operating systems like Amazon Linux etc which does not have a
IPA-Client, we generally use SSSD to get things working.

In such cases, what would be optimal way to configure the SRV records as
--domain parameter won't be present.




On Mon, Jan 25, 2016 at 5:16 PM, David Kupka  wrote:

> On 25/01/16 12:08, Zeal Vora wrote:
>
>> Thanks Petr.
>>
>> So if the domain is example.com, in DNS, what would be the IP associated
>> with it ?
>>
>> As there are 2 master servers, each of them will have different IP
>> address.
>>
>> On Mon, Jan 25, 2016 at 4:34 PM, Petr Spacek  wrote:
>>
>> On 25.1.2016 10:47, Zeal Vora wrote:
>>>
 Hi

 I have setup a multi-master IPA and it seems to be working fine.

 The clients ( laptops and servers ) are not using the DNS of IPA.

 I was wondering, while configuring ipa-client, which server do I

>>> reference
>>>
 to when it asks the ipa-server hostname ?

 Both the master server has different hostnames.

 master1.example.com  ( Master 1 )
 master2.example.com  ( Master 2 )

>>>
>>> Specify only --domain option and do not use --server option at all. In
>>> will
>>> enable server auto-detection using DNS SRV records and you will not need
>>> to
>>> worry about adding/removing servers because all clients will
>>> automatically
>>> pick the new list up.
>>>
>>> --
>>> Petr^2 Spacek
>>>
>>> --
>>> Manage your subscription for the Freeipa-users mailing list:
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>> Go to http://freeipa.org for more info on the project
>>>
>>>
>>
>>
>>
> The '--domain' parameter is for client installer to form DNS request.
> Request that is sent is the same as one sent by this command:
> dig -t SRV _ldap._tcp.
>
> It then receiver list of records similar to this one:
> 100 0 389 
> 100 0 389 
>
> Installer then goes through the list and checks if it's really FreeIPA
> server and first one that passes is used. When IP address is needed it can
> be resolved from the name included in SRV response.
>
> HTH,
> --
> David Kupka
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Master Error with two Master CentOS 7.2

[Günther J . Niederwimmer]

Hello Ludwig,

Am Dienstag, 26. Januar 2016, 11:03:27 CET schrieb Ludwig Krispenz:
> On 01/26/2016 09:45 AM, Günther J. Niederwimmer wrote:
> > Hello List,
> > 
> > I set up a CentOS 7.2 System with two master Server now I found this 1000
> > x
> > Error on my first master?
> > 
> > attrlist_replace - attr_replace (nsslapd-referral,
> > ldap://ipa1.xxx.at:389/ o%3Dipaca) failed.
> 
> did you install and reinstall the replica on the same machine ? The
> message is usually related to removed replicaid, which was not properly
> cleaned.

Yes, I must delete and reinstall the Replica but I have all cleanup I found in 
the DOC

ipa-replica-manage del ipa1..at
ipa-csreplica-manage del ipa1...at

and create a new

ipa-replica-prepare ipa1.xxx.at

the system for ipa1 is a new installed KVM guest., with the same name 
ipa1..at
 
> can you do some searches ?. On both masters check which is the replicaID
> in use and which are the known ruvs:
> ldapsearch -b "cn=config"  "objectclass=nsds5replica" replicaid
> nsds50ruv

Please can you give me the full command I am not a professional  for LDAP 

Thanks 

> > the second is harmless  I read ;-)
> > NSMMReplicationPlugin - replication keep alive entry 

Re: [Freeipa-users] Migration from openLDAP to FreeIPA with qmail.schema

[Martin Kosek]

On 01/26/2016 10:16 AM, wodel youchi wrote:
> Hi,
> 
> I am a newbie in freeipa. I am trying to use it with our mail server.

Cool! What is your version of the FreeIPA server? It will be important for
further investigation.

> Our mail server uses openldap with one external schema : qmail.schema, we
> use it especially for mailQuota, mailAlternateAddress,
> mailForwardingAddress and AccountStatus.
> 
> I tried to import this schema to freeipa using ipa-ldap-updater.
> I am not sure if I succeeded, but when I tried : ipa config-mod
> --addattr=ipaGroupObjectClasses=qmailUser it worked and I can see the
> objectClass.
> 
> 
> [root@ipamaster work]# ipa config-show --all
>   dn: cn=ipaConfig,cn=etc,dc=example,dc=com
>   Longueur maximale du nom d'utilisateur: 32
>   Base du répertoire utilisateur: /home
>   Interprèteur par défaut: /bin/sh
>   Groupe utilisateur par défaut: ipausers
>   Domaine par défaut pour les courriels: example.com
>   Limite de temps d'une recherche: 2
>   Limite de taille d'une recherche: 100
>   Champs de recherche utilisateur: uid,givenname,sn,telephonenumber,ou,title
>   Group search fields: cn,description
>   Activer le mode migration: TRUE
>   Base de sujet de certificat: O=EXAMPLE.COM
>   Classes d'objets de groupe par défaut: top, ipaobject, groupofnames,
> ipausergroup, nestedgroup
>   Classes d'objets utilisateur par défaut: ipaobject, person, top,
> ipasshuser, inetorgperson, organizationalperson,
>krbticketpolicyaux,
> krbprincipalaux, *qmailUser*, inetuser, posixaccount
>   Notification d'expiration de mot de passe (jours): 4
>   Fonctionnalités du greffon mots de passe: AllowNThash
>   Ordre de la mappe des utilisateurs SELinux:
> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
>   Utilisateur SELinux par défaut: unconfined_u:s0-s0:c0.c1023
>   Types de PAC par défaut: nfs:NONE, MS-PAC
>   aci: (targetattr = "cn || createtimestamp || entryusn ||
> ipacertificatesubjectbase || ipaconfigstring || ipacustomfields ||
>ipadefaultemaildomain || ipadefaultloginshell ||
> ipadefaultprimarygroup || ipagroupobjectclasses ||
>ipagroupsearchfields || ipahomesrootdir || ipakrbauthzdata ||
> ipamaxusernamelength || ipamigrationenabled ||
>ipapwdexpadvnotify || ipasearchrecordslimit || ipasearchtimelimit ||
> ipaselinuxusermapdefault ||
>ipaselinuxusermaporder || ipauserauthtype || ipauserobjectclasses ||
> ipausersearchfields || modifytimestamp ||
>objectclass")(targetfilter = "(objectclass=ipaguiconfig)")(version
> 3.0;acl "permission:System: Read Global
>Configuration";allow (compare,read,search) userdn = "ldap:///all;;)
>   cn: ipaConfig
>   objectclass: ipaConfigObject, nsContainer, top, ipaGuiConfig,
> ipaUserAuthTypeClass
> 
> Then I tried to migrate openldap's accounts, but without luck so far
> #ipa -v migrate-ds --with-compat --bind-dn "cn=admin,dc=example,dc=com"
> --continue ldap://192.168.1.121:389
> ---
> migrate-ds:
> ---
> Migrated:
> Failed user:
>   jean.doe: Type or value exists:
>   jeane.doe: Type or value exists:
>  Failed group:
> --
> No users/groups were migrated from ldap://192.168.1.121:389
> 
> 
> Here is an entry from openldap
> dn: uid=jeane.doe,ou=people,dc=example,dc=com
> loginShell: /bin/bash
> gidNumber: 1000
> objectClass: top
> objectClass: qmailUser
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: person
> objectClass: shadowAccount
> objectClass: organizationalPerson
> mail: jeane@example.com
> givenName: DOE
> uid: jeane.doe
> uidNumber: 1002
> displayName: Jeane Doe
> homeDirectory: /var/vmail/jeane.doe
> accountStatus: yes
> mailMessageStore: /var/vmail/jeane.doe
> structuralObjectClass: inetOrgPerson
> entryUUID: 3e8ee290-166f-1035-94d7-ef8fa27fbe71
> creatorsName: cn=admin,dc=example,dc=com
> createTimestamp: 20151103120748Z
> userPassword:: e1NTSEF9K2ZYQnQrMnZsbmVURlVEaG5FdjlZdkhTNFpvNjVMSVQ=
> mailQuotaSize: 1024000
> sn: Jeane
> cn: DOE
> entryCSN: 20160125162455.613052Z#00#000#00
> modifiersName: cn=admin,dc=example,dc=com
> modifyTimestamp: 20160125162455Z
> 
> What does "Type or value exists" means?

That normally means that you have the same value for LDAP attribute twice or
that you are trying to add multiple values for a single valued attribute. I
wonder if we could get better logging, like how exactly the entry looks like
before it is added to LDAP.

But right now, I cannot think about a better way than to updating
/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py
on the FreeIPA server the following way (new print statement)

try:
print entry_attrs
ldap.add_entry(entry_attrs)
except errors.ExecutionError, e:

, restarting the httpd service and sending us the /var/log/httpd/error_log
after the next migration attempt. Maybe Jan (CCed) knows a better way.

> PS: the 

Re: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Martin Kosek]

On 01/26/2016 09:45 PM, Ash Alam wrote:
> I didnt want to dig up an old thread but i am running into this issue. The
> old thread points to Pki 10.2.6 as the solution but i am not seeing that
> package on centos 7.2.
> 
> STDERR: ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to
> configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f'
> '/tmp/tmpHfdvFD'' returned non-zero exit status 1

CCing David and Endi, they might have an idea what is wrong. There were several
recent fixes, to again fix RHEL-6 to RHEL-7 migration, we would need to check
if you have them installed. As for your RHEL-6 IPA setup, is it running with
External CA, i.e. IPA CA with being signed with other CA?

> 
> On Tue, Jan 26, 2016 at 12:14 PM, Ash Alam  wrote:
> 
>> thank you! Out of curiosity has anyone been able to automate this using
>> chef/puppet etc?
>>
>> On Tue, Jan 26, 2016 at 10:56 AM, Martin Kosek  wrote:
>>
>>> Did you follow the instructions in the error message? There is also a
>>> longer
>>> description here:
>>>
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
>>>
>>> Martin
>>>
>>> On 01/26/2016 04:38 PM, Ash Alam wrote:
 I wanted to follow up on this as i finally gotten around to doing the
 upgrade. I an running into this error. I also found a bugzilla ticket.
>>> Do
 you have to do some type of schema upgrade like you do with active
 directory?

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

 STDERR: ipa : CRITICAL The master CA directory server does
>>> not
 have necessary schema. Please copy the following script to all CA
>>> masters
 and run it on them: /usr/share/ipa/copy-schema-to-ca.py

 If you are certain that this is a false positive, use
 --skip-schema-check.

 ipa.ipapython.install.cli.install_tool(Replica): ERRORIPA schema
 missing on master CA directory server



 Thank You




 On Fri, Nov 20, 2015 at 11:13 AM, Martin Kosek 
>>> wrote:

> On 11/20/2015 04:08 PM, Ash Alam wrote:
>
>> Most of the clients in my env are centos 6.6 with ipa 3.0.0 client
>> installed. I
>> if bring up a replica on centos 7.2 with ipa 4.2.3 server and then
>>> start
>> phasing out the older 3.0.0 servers. Will the client that are still
>> running the
>> older client software still work?
>>
>
> It should, yes. It is expected that there are RHEL/CentOS-6 clients
>>> with
> RHEL-7 FreeIPA servers. The older clients just won't be able to use the
> newest features.
>
>
>> On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek > > wrote:
>>
>> On 11/19/2015 11:03 PM, Ash Alam wrote:
>>
>> Hello All
>>
>> I am looking for some advice on upgrading. Currently our
>>> FreeIPA
>> servers are
>> 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7.
>>> This
>> upgrade path
>> is not possible per IPA documentation. Minimum version
>>> required
>> is 3.3.x. I
>> have also found that cenos6 does not provide anything past
>>> 3.0.0.
>>
>>
>> And it won't. There are no plans in updating FreeIPA version in
>> RHEL/CentOS-6.x, we encourage people who want the new features to
>> migrate
>> to RHEL-7.x:
>>
>>
>>
>>> http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS
>>
>>
>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
>>
>> If you want to wait on CentOS-7.2, it should be in works now:
>> http://seven.centos.org/2015/11/rhel-7-2-released-today/
>>
>> One idea is to upgrade to 3.3.x first and then upgrade to
>>> 4.2.3
>> on centos7.
>> This is harder since centos does not provide this. The other
>> issue is if
>> 3.0/3.3 client will be supported with 4.2.3 server.
>>
>>
>> The right way is to migrate via creating replicas in
>>> RHEL/CentOS-7.x
>> and
>> slowly deprecating RHEL/CentOS-6 ones. Detailed procedure in the
>> links above.
>>
>>
>>
>

>>>
>>>
>>
> 

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

Re: [Freeipa-users] FREAK Vulnerability

[Martin Kosek]

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

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

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

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

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

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

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

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

Re: [Freeipa-users] Freeipa 4.3.0 : Forward only Policy fails for reverse lookup zones

[Nathan Peters]

I don't know if this is a bug or intended behavior, but if I set those values 
also in named.conf manually, forwarding of arpa zones works.

I had to do this  :
---snip---
  forward only;
forwarders { 10.21.0.14; 10.21.0.15; };
---snip---

Previously my file looked like this
---snip ---
  forward only;
  forwarders { };
---snip---
But that shouldn't have mattered, because the server was properly using the 
ldap global settings for forwarding regular lookups and overriding the 
named.conf settings properly.


From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Nathan Peters
Sent: January-26-16 6:03 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Freeipa 4.3.0 : Forward only Policy fails for reverse 
lookup zones

I have my FreeIPA server setup with a forward only policy for DNS.

If I perform an nslookup against either of the configured forward servers, I 
can do a reverse lookup properly.

If I perform the same nslookup against my local server, it will not find the 
entry.

I have confirmed that there are no conflicting zones or reverse zones on my 
FreeIPA server.

Tests below :

1.Show forwarding configuration

2.Test lookup against localhost of own domain name (prove we can find 
records we host as primary)

3.Prove we can do forward lookup on the host that we can't reverse lookup on

4.Reverse lookup fails against localhost

5.Reverse lookup succeeds against forward server 1

6.Reverse lookup succeeds against forward server 2

So... if I am set to always forward, and I don't host this domain (or a parent 
of it), and I can lookup the server on my forwarded domains,

Then... why can't that query get forwarded properly according to my forwarding 
settings ?

1. ===
[root@dc2-ipa-dev-van ~]# ipa dnsconfig-show
  Global forwarders: 10.21.0.15, 10.21.0.14
  Forward policy: only
  Allow PTR sync: TRUE
2. ===
  [root@dc2-ipa-dev-van ~]# nslookup
> dc2-ipa-dev-van.dev-mydomain.net
Server: 127.0.0.1
Address:127.0.0.1#53

Name:   dc2-ipa-dev-van.dev-mydomain.net
Address: 10.21.0.98
3. ===
> officedc2.office.mydomain.net
Server: 127.0.0.1
Address:127.0.0.1#53

Non-authoritative answer:
Name:   officedc2.office.mydomain.net
Address: 10.6.60.6
4. ===
> 10.6.60.6
Server: 127.0.0.1
Address:127.0.0.1#53

** server can't find 6.60.6.10.in-addr.arpa: NXDOMAIN
5. ===
> server 10.21.0.14
Default server: 10.21.0.14
Address: 10.21.0.14#53
> 10.6.60.6
Server: 10.21.0.14
Address:10.21.0.14#53

Non-authoritative answer:
6.60.6.10.in-addr.arpa  name = officedc2.office.mydomain.net.

Authoritative answers can be found from:
6. ===
> server 10.21.0.15
Default server: 10.21.0.15
Address: 10.21.0.15#53
> 10.6.60.6
Server: 10.21.0.15
Address:10.21.0.15#53

Non-authoritative answer:
6.60.6.10.in-addr.arpa  name = officedc2.office.mydomain.net.

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

Re: [Freeipa-users] ipa-trust and SRV records

[Alexander Bokovoy]

On Wed, 27 Jan 2016, Simpson Lachlan wrote:

At the end of the installation of the ipa-adtrust-install, there is a
message along the lines of:

Add the following service records to your DNS server for DNS zone
unix.co.org.au:

_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs
_ldap._tcp.dc._msdcs
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
_kerberos._tcp.dc._msdcs
_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs
_kerberos._udp.dc._msdcs


Which has, I think, been the cause of all of my grief.

Do these SRV records in AD represent the minimum DNS set up required in
Active Directory (my setup is a one way trust from FreeIPA to an AD
over which I have no control, and all DNS is passed up to AD)?

These records are required to exist in the DNS zone of IPA.


These records are required so that the FreeIPA server can find the AD
servers?

These records are required so that AD DCs know where to find IPA domain
controllers.


Also, is it fair to infer that Default-First-Site-Name is in our case co.org.au?

No, this is literal string, it has to be this way.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] ipa-admintools version incompatibility

[Martin Kosek]

Adding freeipa-users list back, so that others benefit from the discussion.

On 01/26/2016 07:47 PM, Izzo, Anthony wrote:
> The error I'm getting is that the option "raw" is invalid.  The dnsrecord-del 
> command includes a "--raw" switch on RHEL6, but not on RHEL7.  I am not using 
> the switch, but according to the debug output, RHEL6 is passing "raw" (as a 
> parameter with a value) unconditionally, with the value indicating whether 
> the flag was selected or not.  Since RHEL7 does not accept "raw", it fails.

Ah, I see. It looks like we broke forward compatibility of this command in
https://fedorahosted.org/freeipa/ticket/3503
I think dnsrecord-del should at least "eat" the options withour raising error.
CCing Martin Basti to eventually create ticket for it. Martin, can you think of
any workaround that Anthony could use, besides using nsupdate?

> I hadn't thought about using the nsupdate tool, I'll give that a shot.  
> Thanks.
> 
> Tony
> 
> -Original Message-
> From: Martin Kosek [mailto:mko...@redhat.com] 
> Sent: Tuesday, January 26, 2016 11:10 AM
> To: Izzo, Anthony (U.S. Person) ; freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] ipa-admintools version incompatibility
> 
> On 01/26/2016 04:22 PM, Izzo, Anthony wrote:
>> I have a FreeIPA 4.2 server (on RHEL7) and a FreeIPA 3.0 client (on RHEL6).  
>> I am aware of the incompatibility between versions for ipa-admintools (in my 
>> case I'm trying to use ipa dnsrecord-del).  I was just wondering if there is 
>> a workaround that would allow me, from my 3.0 client, to delete a DNS PTR 
>> record on the 4.2 server, since I can't use the ipa dnsrecord-del command 
>> (the APIs are different, and the server responds that I've sent an invalid 
>> option).  Thanks.
> 
> That's strange, client should be forward compatible already:
> 
> http://www.freeipa.org/page/Client#IPA_management_tool
> 
> , i.e. RHEL-6 clients should be able to update RHEL-7 servers. We would know 
> more if you send us the error.
> 
> Anyway, given you are only updating DNS, maybe you could just use standard 
> Kerberos-authenticated DNS update (nsupdate tool), to delete that PTR record?
> 

-- 
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] Master Error with two Master CentOS 7.2

[Günther J . Niederwimmer]

Hello List,

I set up a CentOS 7.2 System with two master Server now I found this 1000 x 
Error on my first master?

attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.xxx.at:389/
o%3Dipaca) failed.

the second is harmless  I read ;-)
NSMMReplicationPlugin - replication keep alive entry 

Re: [Freeipa-users] Migration from openLDAP to FreeIPA with qmail.schema

[wodel youchi]

Hi,

In the above log (httpd log) the LDAPEntry contains qmailuser and qmailUser
objectClasses, I don't know if this is what is causing the problem.

Another thing, I can't import groups as well, I did add a simple group to
my ldap
dn: ou=groups,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: groups
structuralObjectClass: organizationalUnit

dn: cn=vmail,ou=groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
gidNumber: 5000
structuralObjectClass: posixGroup
cn: vmail

When I launch the migration command I get

ipa: ERROR: La recherche LDAP group ne renvoie aucun résultat (base de
recherche : ou=groups,dc=example,dc=com, classe d'objet :
groupofuniquenames, groupofnames)

any idea?

Regards.

2016-01-26 13:42 GMT+01:00 wodel youchi :

> Hi again,
>
> This is what I get from httpd error_log
>
> [Tue Jan 26 13:38:02.394757 2016] [:error] [pid 7427] ipa: WARNING: GID
> number 1000 of migrated user jean.doe does not point to a known group.
> [Tue Jan 26 13:38:02.397928 2016] [:error] [pid 7427]
> LDAPEntry(ipapython.dn.DN('uid=jean.doe,cn=users,cn=accounts,dc=example,dc=com'),
> {u'mailQuotaSize': ['2048000'], u'cn': ['DOE'], u'uid': [u'jean.doe'],
> u'objectClass': [u'ipaobject', u'organizationalperson', u'qmailuser',
> u'top', u'ipasshuser', u'inetorgperson', u'person', u'krbticketpolicyaux',
> u'krbprincipalaux', u'shadowaccount', u'qmailUser', u'inetuser',
> u'posixaccount'], u'loginShell': ['/bin/bash'], u'uidNumber': ['1001'],
> u'gidNumber': [u'1000'], u'ipauniqueid': ['autogenerate'],
> u'krbprincipalname': [u'jean@example.com'], u'mailMessageStore':
> ['/var/vmail/jean.doe'], u'description': ['__no_upg__'], u'displayName':
> ['Jean Doe'], u'userPassword': ['{SSHA}NIxCImzQDagloyVdMtheC4wDMUImxW85'],
> u'accountStatus': ['yes'], u'mailAlternateAddress': ['r...@example.com', '
> postmas...@example.com'], u'sn': ['Jean'], u'homeDirectory':
> ['/var/vmail/jean.doe'], u'mail': ['jean@example.com'], u'givenName':
> ['DOE']})
> [Tue Jan 26 13:38:02.398937 2016] [:error] [pid 7427] ipa: WARNING: GID
> number 1000 of migrated user jeane.doe does not point to a known group.
> [Tue Jan 26 13:38:02.399703 2016] [:error] [pid 7427]
> LDAPEntry(ipapython.dn.DN('uid=jeane.doe,cn=users,cn=accounts,dc=example,dc=com'),
> {u'mailQuotaSize': ['1024000'], u'cn': ['DOE'], u'uid': [u'jeane.doe'],
> u'objectClass': [u'ipaobject', u'organizationalperson', u'qmailuser',
> u'top', u'ipasshuser', u'inetorgperson', u'person', u'krbticketpolicyaux',
> u'krbprincipalaux', u'shadowaccount', u'qmailUser', u'inetuser',
> u'posixaccount'], u'loginShell': ['/bin/bash'], u'uidNumber': ['1002'],
> u'gidNumber': [u'1000'], u'ipauniqueid': ['autogenerate'],
> u'krbprincipalname': [u'jeane@example.com'], u'mailMessageStore':
> ['/var/vmail/jeane.doe'], u'description': ['__no_upg__'], u'displayName':
> ['Jeane Doe'], u'userPassword': ['{SSHA}+fXBt+2vlneTFUDhnEv9YvHS4Zo65LIT'],
> u'accountStatus': ['yes'], u'sn': ['Jeane'], u'homeDirectory':
> ['/var/vmail/jeane.doe'], u'mail': ['jeane@example.com'],
> u'givenName': ['DOE']})
>
> Regards.
>
> 2016-01-26 11:22 GMT+01:00 wodel youchi :
>
>> Thanks I will try and report back.
>>
>> I am using Centos 7.2x64 with latest updates
>>
>> and ipa-server-4.2.0-15.el7.centos.3.x86_64
>>
>> Regards
>>
>> 2016-01-26 10:53 GMT+01:00 Martin Kosek :
>>
>>> On 01/26/2016 10:16 AM, wodel youchi wrote:
>>> > Hi,
>>> >
>>> > I am a newbie in freeipa. I am trying to use it with our mail server.
>>>
>>> Cool! What is your version of the FreeIPA server? It will be important
>>> for
>>> further investigation.
>>>
>>> > Our mail server uses openldap with one external schema : qmail.schema,
>>> we
>>> > use it especially for mailQuota, mailAlternateAddress,
>>> > mailForwardingAddress and AccountStatus.
>>> >
>>> > I tried to import this schema to freeipa using ipa-ldap-updater.
>>> > I am not sure if I succeeded, but when I tried : ipa config-mod
>>> > --addattr=ipaGroupObjectClasses=qmailUser it worked and I can see the
>>> > objectClass.
>>> >
>>> >
>>> > [root@ipamaster work]# ipa config-show --all
>>> >   dn: cn=ipaConfig,cn=etc,dc=example,dc=com
>>> >   Longueur maximale du nom d'utilisateur: 32
>>> >   Base du répertoire utilisateur: /home
>>> >   Interprèteur par défaut: /bin/sh
>>> >   Groupe utilisateur par défaut: ipausers
>>> >   Domaine par défaut pour les courriels: example.com
>>> >   Limite de temps d'une recherche: 2
>>> >   Limite de taille d'une recherche: 100
>>> >   Champs de recherche utilisateur:
>>> uid,givenname,sn,telephonenumber,ou,title
>>> >   Group search fields: cn,description
>>> >   Activer le mode migration: TRUE
>>> >   Base de sujet de certificat: O=EXAMPLE.COM
>>> >   Classes d'objets de groupe par défaut: top, ipaobject, groupofnames,
>>> > ipausergroup, nestedgroup
>>> >   Classes d'objets utilisateur par défaut: ipaobject, person, top,
>>> > ipasshuser, 

Re: [Freeipa-users] Master Error with two Master CentOS 7.2

[Ludwig Krispenz]

On 01/26/2016 12:30 PM, Günther J. Niederwimmer wrote:

Hello Ludwig,

Am Dienstag, 26. Januar 2016, 11:03:27 CET schrieb Ludwig Krispenz:

On 01/26/2016 09:45 AM, Günther J. Niederwimmer wrote:

Hello List,

I set up a CentOS 7.2 System with two master Server now I found this 1000
x
Error on my first master?

attrlist_replace - attr_replace (nsslapd-referral,
ldap://ipa1.xxx.at:389/ o%3Dipaca) failed.

did you install and reinstall the replica on the same machine ? The
message is usually related to removed replicaid, which was not properly
cleaned.

Yes, I must delete and reinstall the Replica but I have all cleanup I found in
the DOC

ipa-replica-manage del ipa1..at
ipa-csreplica-manage del ipa1...at

and create a new

ipa-replica-prepare ipa1.xxx.at

the system for ipa1 is a new installed KVM guest., with the same name
ipa1..at
  

can you do some searches ?. On both masters check which is the replicaID
in use and which are the known ruvs:
ldapsearch -b "cn=config"  "objectclass=nsds5replica" replicaid
nsds50ruv

Please can you give me the full command I am not a professional  for LDAP
ldapsearch -LLL -o ldif-wrap=no -x -h  -p 389  -D "cn=directory 
manager" -W -b "cn=config" "objectclass=nsds5replica" nsds5replicaid 
nsds50ruv


for host insert your masters


Thanks


the second is harmless  I read ;-)
NSMMReplicationPlugin - replication keep alive entry 

Re: [Freeipa-users] Migration from openLDAP to FreeIPA with qmail.schema

[Martin Kosek]

On 01/26/2016 02:20 PM, wodel youchi wrote:
> Hi,
> 
> In the above log (httpd log) the LDAPEntry contains qmailuser and qmailUser
> objectClasses, I don't know if this is what is causing the problem.

That's probably it. Can you please try to lowercaser 'qmailUser' in the FreeIPA
config and try the migration again?

> Another thing, I can't import groups as well, I did add a simple group to
> my ldap
> dn: ou=groups,dc=example,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: groups
> structuralObjectClass: organizationalUnit
> 
> dn: cn=vmail,ou=groups,dc=example,dc=com
> objectClass: top
> objectClass: posixGroup
> gidNumber: 5000
> structuralObjectClass: posixGroup
> cn: vmail
> 
> When I launch the migration command I get
> 
> ipa: ERROR: La recherche LDAP group ne renvoie aucun résultat (base de
> recherche : ou=groups,dc=example,dc=com, classe d'objet :
> groupofuniquenames, groupofnames)
> 
> any idea?

I cannot really read French, but I suspect you could use the option

  --group-objectclass=STR
Objectclasses used to search for group entries in DS

to specify the objectclass the migration should search (posixGroup in your case)

> 
> Regards.
> 
> 2016-01-26 13:42 GMT+01:00 wodel youchi :
> 
>> Hi again,
>>
>> This is what I get from httpd error_log
>>
>> [Tue Jan 26 13:38:02.394757 2016] [:error] [pid 7427] ipa: WARNING: GID
>> number 1000 of migrated user jean.doe does not point to a known group.
>> [Tue Jan 26 13:38:02.397928 2016] [:error] [pid 7427]
>> LDAPEntry(ipapython.dn.DN('uid=jean.doe,cn=users,cn=accounts,dc=example,dc=com'),
>> {u'mailQuotaSize': ['2048000'], u'cn': ['DOE'], u'uid': [u'jean.doe'],
>> u'objectClass': [u'ipaobject', u'organizationalperson', u'qmailuser',
>> u'top', u'ipasshuser', u'inetorgperson', u'person', u'krbticketpolicyaux',
>> u'krbprincipalaux', u'shadowaccount', u'qmailUser', u'inetuser',
>> u'posixaccount'], u'loginShell': ['/bin/bash'], u'uidNumber': ['1001'],
>> u'gidNumber': [u'1000'], u'ipauniqueid': ['autogenerate'],
>> u'krbprincipalname': [u'jean@example.com'], u'mailMessageStore':
>> ['/var/vmail/jean.doe'], u'description': ['__no_upg__'], u'displayName':
>> ['Jean Doe'], u'userPassword': ['{SSHA}NIxCImzQDagloyVdMtheC4wDMUImxW85'],
>> u'accountStatus': ['yes'], u'mailAlternateAddress': ['r...@example.com', '
>> postmas...@example.com'], u'sn': ['Jean'], u'homeDirectory':
>> ['/var/vmail/jean.doe'], u'mail': ['jean@example.com'], u'givenName':
>> ['DOE']})
>> [Tue Jan 26 13:38:02.398937 2016] [:error] [pid 7427] ipa: WARNING: GID
>> number 1000 of migrated user jeane.doe does not point to a known group.
>> [Tue Jan 26 13:38:02.399703 2016] [:error] [pid 7427]
>> LDAPEntry(ipapython.dn.DN('uid=jeane.doe,cn=users,cn=accounts,dc=example,dc=com'),
>> {u'mailQuotaSize': ['1024000'], u'cn': ['DOE'], u'uid': [u'jeane.doe'],
>> u'objectClass': [u'ipaobject', u'organizationalperson', u'qmailuser',
>> u'top', u'ipasshuser', u'inetorgperson', u'person', u'krbticketpolicyaux',
>> u'krbprincipalaux', u'shadowaccount', u'qmailUser', u'inetuser',
>> u'posixaccount'], u'loginShell': ['/bin/bash'], u'uidNumber': ['1002'],
>> u'gidNumber': [u'1000'], u'ipauniqueid': ['autogenerate'],
>> u'krbprincipalname': [u'jeane@example.com'], u'mailMessageStore':
>> ['/var/vmail/jeane.doe'], u'description': ['__no_upg__'], u'displayName':
>> ['Jeane Doe'], u'userPassword': ['{SSHA}+fXBt+2vlneTFUDhnEv9YvHS4Zo65LIT'],
>> u'accountStatus': ['yes'], u'sn': ['Jeane'], u'homeDirectory':
>> ['/var/vmail/jeane.doe'], u'mail': ['jeane@example.com'],
>> u'givenName': ['DOE']})
>>
>> Regards.
>>
>> 2016-01-26 11:22 GMT+01:00 wodel youchi :
>>
>>> Thanks I will try and report back.
>>>
>>> I am using Centos 7.2x64 with latest updates
>>>
>>> and ipa-server-4.2.0-15.el7.centos.3.x86_64
>>>
>>> Regards
>>>
>>> 2016-01-26 10:53 GMT+01:00 Martin Kosek :
>>>
 On 01/26/2016 10:16 AM, wodel youchi wrote:
> Hi,
>
> I am a newbie in freeipa. I am trying to use it with our mail server.

 Cool! What is your version of the FreeIPA server? It will be important
 for
 further investigation.

> Our mail server uses openldap with one external schema : qmail.schema,
 we
> use it especially for mailQuota, mailAlternateAddress,
> mailForwardingAddress and AccountStatus.
>
> I tried to import this schema to freeipa using ipa-ldap-updater.
> I am not sure if I succeeded, but when I tried : ipa config-mod
> --addattr=ipaGroupObjectClasses=qmailUser it worked and I can see the
> objectClass.
>
>
> [root@ipamaster work]# ipa config-show --all
>   dn: cn=ipaConfig,cn=etc,dc=example,dc=com
>   Longueur maximale du nom d'utilisateur: 32
>   Base du répertoire utilisateur: /home
>   Interprèteur par défaut: /bin/sh
>   Groupe utilisateur par défaut: ipausers
>   Domaine par défaut pour les 

[Freeipa-users] ipa-admintools version incompatibility

[Izzo, Anthony]

I have a FreeIPA 4.2 server (on RHEL7) and a FreeIPA 3.0 client (on RHEL6).  I 
am aware of the incompatibility between versions for ipa-admintools (in my case 
I'm trying to use ipa dnsrecord-del).  I was just wondering if there is a 
workaround that would allow me, from my 3.0 client, to delete a DNS PTR record 
on the 4.2 server, since I can't use the ipa dnsrecord-del command (the APIs 
are different, and the server responds that I've sent an invalid option).  
Thanks.

Tony


-- 
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] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Ash Alam]

I wanted to follow up on this as i finally gotten around to doing the
upgrade. I an running into this error. I also found a bugzilla ticket. Do
you have to do some type of schema upgrade like you do with active
directory?

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

STDERR: ipa : CRITICAL The master CA directory server does not
have necessary schema. Please copy the following script to all CA masters
and run it on them: /usr/share/ipa/copy-schema-to-ca.py

If you are certain that this is a false positive, use
--skip-schema-check.

ipa.ipapython.install.cli.install_tool(Replica): ERRORIPA schema
missing on master CA directory server



Thank You




On Fri, Nov 20, 2015 at 11:13 AM, Martin Kosek  wrote:

> On 11/20/2015 04:08 PM, Ash Alam wrote:
>
>> Most of the clients in my env are centos 6.6 with ipa 3.0.0 client
>> installed. I
>> if bring up a replica on centos 7.2 with ipa 4.2.3 server and then start
>> phasing out the older 3.0.0 servers. Will the client that are still
>> running the
>> older client software still work?
>>
>
> It should, yes. It is expected that there are RHEL/CentOS-6 clients with
> RHEL-7 FreeIPA servers. The older clients just won't be able to use the
> newest features.
>
>
>> On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek > > wrote:
>>
>> On 11/19/2015 11:03 PM, Ash Alam wrote:
>>
>> Hello All
>>
>> I am looking for some advice on upgrading. Currently our FreeIPA
>> servers are
>> 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This
>> upgrade path
>> is not possible per IPA documentation. Minimum version required
>> is 3.3.x. I
>> have also found that cenos6 does not provide anything past 3.0.0.
>>
>>
>> And it won't. There are no plans in updating FreeIPA version in
>> RHEL/CentOS-6.x, we encourage people who want the new features to
>> migrate
>> to RHEL-7.x:
>>
>>
>> http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS
>>
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
>>
>> If you want to wait on CentOS-7.2, it should be in works now:
>> http://seven.centos.org/2015/11/rhel-7-2-released-today/
>>
>> One idea is to upgrade to 3.3.x first and then upgrade to 4.2.3
>> on centos7.
>> This is harder since centos does not provide this. The other
>> issue is if
>> 3.0/3.3 client will be supported with 4.2.3 server.
>>
>>
>> The right way is to migrate via creating replicas in RHEL/CentOS-7.x
>> and
>> slowly deprecating RHEL/CentOS-6 ones. Detailed procedure in the
>> links above.
>>
>>
>>
>
-- 
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] Master Error with two Master CentOS 7.2

[Günther J . Niederwimmer]

Hello Ludwig,

Am Dienstag, 26. Januar 2016, 14:48:31 CET schrieb Ludwig Krispenz:
> On 01/26/2016 12:30 PM, Günther J. Niederwimmer wrote:

> > Am Dienstag, 26. Januar 2016, 11:03:27 CET schrieb Ludwig Krispenz:
> >> On 01/26/2016 09:45 AM, Günther J. Niederwimmer wrote:

> >>> I set up a CentOS 7.2 System with two master Server now I found this
> >>> 1000
> >>> x
> >>> Error on my first master?
> >>> 
> >>> attrlist_replace - attr_replace (nsslapd-referral,
> >>> ldap://ipa1.xxx.at:389/ o%3Dipaca) failed.
> >> 
> >> did you install and reinstall the replica on the same machine ? The
> >> message is usually related to removed replicaid, which was not properly
> >> cleaned.
> > 
> > Yes, I must delete and reinstall the Replica but I have all cleanup I
> > found in the DOC
> > 
> > ipa-replica-manage del ipa1..at
> > ipa-csreplica-manage del ipa1...at
> > 
> > and create a new
> > 
> > ipa-replica-prepare ipa1.xxx.at
> > 
> > the system for ipa1 is a new installed KVM guest., with the same name
> > ipa1..at
> > 
> >> can you do some searches ?. On both masters check which is the replicaID
> >> in use and which are the known ruvs:
> >> ldapsearch -b "cn=config"  "objectclass=nsds5replica" replicaid
> >> nsds50ruv
> > 
> > Please can you give me the full command I am not a professional  for LDAP
> 
> ldapsearch -LLL -o ldif-wrap=no -x -h  -p 389  -D "cn=directory
> manager" -W -b "cn=config" "objectclass=nsds5replica" nsds5replicaid
> nsds50ruv
 
> for host insert your masters
Thanks for the help.

The original master

dn: cn=replica,cn=dc\3Desslmaier\2Cdc\3Dat,cn=mapping tree,cn=config
nsds5replicaid: 4
nsds50ruv: {replicageneration} 562f579c0004
nsds50ruv: {replica 4 ldap://ipa.esslmaier.at:389} 562f57b70004 
56a792640004
nsds50ruv: {replica 5 ldap://ipa1.esslmaier.at:389} 568a1fa20005 
56a5cf7300020005

dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nsds5replicaid: 96
nsds50ruv: {replicageneration} 562f57e30060
nsds50ruv: {replica 96 ldap://ipa.esslmaier.at:389} 562f58040060 
56a790210060
nsds50ruv: {replica 91 ldap://ipa1.esslmaier.at:389} 568a1ff7005b 
568a20250006005b
nsds50ruv: {replica 97 ldap://ipa1.esslmaier.at:389} 562f58110061 
5630a9c40061

The first replica master.

nsds5replicaid: 5
nsds50ruv: {replicageneration} 562f579c0004
nsds50ruv: {replica 5 ldap://ipa1.esslmaier.at:389} 568a1fa20005 
56a793fc0005
nsds50ruv: {replica 4 ldap://ipa.esslmaier.at:389} 562f57b70004 
56a792640004

dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nsds5replicaid: 91
nsds50ruv: {replicageneration} 562f57e30060
nsds50ruv: {replica 91 ldap://ipa1.esslmaier.at:389} 568a1ff7005b 
568a20250006005b
nsds50ruv: {replica 96 ldap://ipa.esslmaier.at:389} 562f58040060 
56a793a50060
nsds50ruv: {replica 97 ldap://ipa1.esslmaier.at:389} 562f58110061 
5630a9c40061


> >>> Is this a bad Error ?
> >>> 
> >>> Can I do anything
> >>> 
> >>> Thanks for a answer,


-- 
mit freundlichen Grüßen / best regards,

  Günther J. Niederwimmer

-- 
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] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Martin Kosek]

Did you follow the instructions in the error message? There is also a longer
description here:

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

Martin

On 01/26/2016 04:38 PM, Ash Alam wrote:
> I wanted to follow up on this as i finally gotten around to doing the
> upgrade. I an running into this error. I also found a bugzilla ticket. Do
> you have to do some type of schema upgrade like you do with active
> directory?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1235766
> 
> STDERR: ipa : CRITICAL The master CA directory server does not
> have necessary schema. Please copy the following script to all CA masters
> and run it on them: /usr/share/ipa/copy-schema-to-ca.py
> 
> If you are certain that this is a false positive, use
> --skip-schema-check.
> 
> ipa.ipapython.install.cli.install_tool(Replica): ERRORIPA schema
> missing on master CA directory server
> 
> 
> 
> Thank You
> 
> 
> 
> 
> On Fri, Nov 20, 2015 at 11:13 AM, Martin Kosek  wrote:
> 
>> On 11/20/2015 04:08 PM, Ash Alam wrote:
>>
>>> Most of the clients in my env are centos 6.6 with ipa 3.0.0 client
>>> installed. I
>>> if bring up a replica on centos 7.2 with ipa 4.2.3 server and then start
>>> phasing out the older 3.0.0 servers. Will the client that are still
>>> running the
>>> older client software still work?
>>>
>>
>> It should, yes. It is expected that there are RHEL/CentOS-6 clients with
>> RHEL-7 FreeIPA servers. The older clients just won't be able to use the
>> newest features.
>>
>>
>>> On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek >> > wrote:
>>>
>>> On 11/19/2015 11:03 PM, Ash Alam wrote:
>>>
>>> Hello All
>>>
>>> I am looking for some advice on upgrading. Currently our FreeIPA
>>> servers are
>>> 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7. This
>>> upgrade path
>>> is not possible per IPA documentation. Minimum version required
>>> is 3.3.x. I
>>> have also found that cenos6 does not provide anything past 3.0.0.
>>>
>>>
>>> And it won't. There are no plans in updating FreeIPA version in
>>> RHEL/CentOS-6.x, we encourage people who want the new features to
>>> migrate
>>> to RHEL-7.x:
>>>
>>>
>>> http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS
>>>
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
>>>
>>> If you want to wait on CentOS-7.2, it should be in works now:
>>> http://seven.centos.org/2015/11/rhel-7-2-released-today/
>>>
>>> One idea is to upgrade to 3.3.x first and then upgrade to 4.2.3
>>> on centos7.
>>> This is harder since centos does not provide this. The other
>>> issue is if
>>> 3.0/3.3 client will be supported with 4.2.3 server.
>>>
>>>
>>> The right way is to migrate via creating replicas in RHEL/CentOS-7.x
>>> and
>>> slowly deprecating RHEL/CentOS-6 ones. Detailed procedure in the
>>> links above.
>>>
>>>
>>>
>>
> 

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

Re: [Freeipa-users] ipa-admintools version incompatibility

[Martin Kosek]

On 01/26/2016 04:22 PM, Izzo, Anthony wrote:
> I have a FreeIPA 4.2 server (on RHEL7) and a FreeIPA 3.0 client (on RHEL6).  
> I am aware of the incompatibility between versions for ipa-admintools (in my 
> case I'm trying to use ipa dnsrecord-del).  I was just wondering if there is 
> a workaround that would allow me, from my 3.0 client, to delete a DNS PTR 
> record on the 4.2 server, since I can't use the ipa dnsrecord-del command 
> (the APIs are different, and the server responds that I've sent an invalid 
> option).  Thanks.

That's strange, client should be forward compatible already:

http://www.freeipa.org/page/Client#IPA_management_tool

, i.e. RHEL-6 clients should be able to update RHEL-7 servers. We would know
more if you send us the error.

Anyway, given you are only updating DNS, maybe you could just use standard
Kerberos-authenticated DNS update (nsupdate tool), to delete that PTR record?

-- 
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] Master Error with two Master CentOS 7.2

[Ludwig Krispenz]

Hi,

you got a replicaid (97) leftover form the previous install for the 
o=ipaca backend. The other backend is ok, ipa-replica-manage del did the 
cleanup, but ipa-csreplica-manage doesn't. So you have to clean it 
manually by an ldap command.


Execute the following mod on one of the servers:

ldapmodify -D "cn=directory manager" -W -a
dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: o=ipaca
replica-id: 97
cn: clean 97


Ludwig

On 01/26/2016 04:52 PM, Günther J. Niederwimmer wrote:

Hello Ludwig,

Am Dienstag, 26. Januar 2016, 14:48:31 CET schrieb Ludwig Krispenz:

On 01/26/2016 12:30 PM, Günther J. Niederwimmer wrote:

Am Dienstag, 26. Januar 2016, 11:03:27 CET schrieb Ludwig Krispenz:

On 01/26/2016 09:45 AM, Günther J. Niederwimmer wrote:

I set up a CentOS 7.2 System with two master Server now I found this
1000
x
Error on my first master?

attrlist_replace - attr_replace (nsslapd-referral,
ldap://ipa1.xxx.at:389/ o%3Dipaca) failed.

did you install and reinstall the replica on the same machine ? The
message is usually related to removed replicaid, which was not properly
cleaned.

Yes, I must delete and reinstall the Replica but I have all cleanup I
found in the DOC

ipa-replica-manage del ipa1..at
ipa-csreplica-manage del ipa1...at

and create a new

ipa-replica-prepare ipa1.xxx.at

the system for ipa1 is a new installed KVM guest., with the same name
ipa1..at


can you do some searches ?. On both masters check which is the replicaID
in use and which are the known ruvs:
ldapsearch -b "cn=config"  "objectclass=nsds5replica" replicaid
nsds50ruv

Please can you give me the full command I am not a professional  for LDAP

ldapsearch -LLL -o ldif-wrap=no -x -h  -p 389  -D "cn=directory
manager" -W -b "cn=config" "objectclass=nsds5replica" nsds5replicaid
nsds50ruv
  

for host insert your masters

Thanks for the help.

The original master

dn: cn=replica,cn=dc\3Desslmaier\2Cdc\3Dat,cn=mapping tree,cn=config
nsds5replicaid: 4
nsds50ruv: {replicageneration} 562f579c0004
nsds50ruv: {replica 4 ldap://ipa.esslmaier.at:389} 562f57b70004
56a792640004
nsds50ruv: {replica 5 ldap://ipa1.esslmaier.at:389} 568a1fa20005
56a5cf7300020005

dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nsds5replicaid: 96
nsds50ruv: {replicageneration} 562f57e30060
nsds50ruv: {replica 96 ldap://ipa.esslmaier.at:389} 562f58040060
56a790210060
nsds50ruv: {replica 91 ldap://ipa1.esslmaier.at:389} 568a1ff7005b
568a20250006005b
nsds50ruv: {replica 97 ldap://ipa1.esslmaier.at:389} 562f58110061
5630a9c40061

The first replica master.

nsds5replicaid: 5
nsds50ruv: {replicageneration} 562f579c0004
nsds50ruv: {replica 5 ldap://ipa1.esslmaier.at:389} 568a1fa20005
56a793fc0005
nsds50ruv: {replica 4 ldap://ipa.esslmaier.at:389} 562f57b70004
56a792640004

dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nsds5replicaid: 91
nsds50ruv: {replicageneration} 562f57e30060
nsds50ruv: {replica 91 ldap://ipa1.esslmaier.at:389} 568a1ff7005b
568a20250006005b
nsds50ruv: {replica 96 ldap://ipa.esslmaier.at:389} 562f58040060
56a793a50060
nsds50ruv: {replica 97 ldap://ipa1.esslmaier.at:389} 562f58110061
5630a9c40061



Is this a bad Error ?

Can I do anything

Thanks for a answer,




--
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] Migration from openLDAP to FreeIPA with qmail.schema

[wodel youchi]

Hi,

For the first problem I redid the import using this syntax
ipa -d -v migrate-ds --bind-dn "cn=admin,dc=example,dc=com" --with-compat
--user-ignore-objectclass qmailuser --continue ldap://192.168.1.121:389

and it worked, all accounts were imported successfully.

The thing I don't know where the query is getting qmailuser, since the
objectclass imported is qmailUser!!!

About the second problem, the error say (sorry for the french btw) :
Error : the search for LDAP group do not return any result (search
base ou=groups,dc=example,dc=com,
objectClass : groupofuniquenames, groupofnames))

And I tested with this command
ipa -d -v migrate-ds --bind-dn "cn=admin,dc=example,dc=com" --with-compat
--group-objectclass=posixGroup --user-ignore-objectclass qmailuser ldap://
192.168.1.121:389

and it worked, as you said I had to add --group-objectclass=posixGroup

Now, I need to added some of attributes to the Webui when creating a new
user, for example mailQuotaSize, is there a way to do that?

Thanks for your help.
Regards.


2016-01-26 16:15 GMT+01:00 Martin Kosek :

> On 01/26/2016 02:20 PM, wodel youchi wrote:
> > Hi,
> >
> > In the above log (httpd log) the LDAPEntry contains qmailuser and
> qmailUser
> > objectClasses, I don't know if this is what is causing the problem.
>
> That's probably it. Can you please try to lowercaser 'qmailUser' in the
> FreeIPA
> config and try the migration again?
>
> > Another thing, I can't import groups as well, I did add a simple group to
> > my ldap
> > dn: ou=groups,dc=example,dc=com
> > objectClass: organizationalUnit
> > objectClass: top
> > ou: groups
> > structuralObjectClass: organizationalUnit
> >
> > dn: cn=vmail,ou=groups,dc=example,dc=com
> > objectClass: top
> > objectClass: posixGroup
> > gidNumber: 5000
> > structuralObjectClass: posixGroup
> > cn: vmail
> >
> > When I launch the migration command I get
> >
> > ipa: ERROR: La recherche LDAP group ne renvoie aucun résultat (base de
> > recherche : ou=groups,dc=example,dc=com, classe d'objet :
> > groupofuniquenames, groupofnames)
> >
> > any idea?
>
> I cannot really read French, but I suspect you could use the option
>
>   --group-objectclass=STR
> Objectclasses used to search for group entries in
> DS
>
> to specify the objectclass the migration should search (posixGroup in your
> case)
>
> >
> > Regards.
> >
> > 2016-01-26 13:42 GMT+01:00 wodel youchi :
> >
> >> Hi again,
> >>
> >> This is what I get from httpd error_log
> >>
> >> [Tue Jan 26 13:38:02.394757 2016] [:error] [pid 7427] ipa: WARNING: GID
> >> number 1000 of migrated user jean.doe does not point to a known group.
> >> [Tue Jan 26 13:38:02.397928 2016] [:error] [pid 7427]
> >>
> LDAPEntry(ipapython.dn.DN('uid=jean.doe,cn=users,cn=accounts,dc=example,dc=com'),
> >> {u'mailQuotaSize': ['2048000'], u'cn': ['DOE'], u'uid': [u'jean.doe'],
> >> u'objectClass': [u'ipaobject', u'organizationalperson', u'qmailuser',
> >> u'top', u'ipasshuser', u'inetorgperson', u'person',
> u'krbticketpolicyaux',
> >> u'krbprincipalaux', u'shadowaccount', u'qmailUser', u'inetuser',
> >> u'posixaccount'], u'loginShell': ['/bin/bash'], u'uidNumber': ['1001'],
> >> u'gidNumber': [u'1000'], u'ipauniqueid': ['autogenerate'],
> >> u'krbprincipalname': [u'jean@example.com'], u'mailMessageStore':
> >> ['/var/vmail/jean.doe'], u'description': ['__no_upg__'], u'displayName':
> >> ['Jean Doe'], u'userPassword':
> ['{SSHA}NIxCImzQDagloyVdMtheC4wDMUImxW85'],
> >> u'accountStatus': ['yes'], u'mailAlternateAddress': ['r...@example.com',
> '
> >> postmas...@example.com'], u'sn': ['Jean'], u'homeDirectory':
> >> ['/var/vmail/jean.doe'], u'mail': ['jean@example.com'],
> u'givenName':
> >> ['DOE']})
> >> [Tue Jan 26 13:38:02.398937 2016] [:error] [pid 7427] ipa: WARNING: GID
> >> number 1000 of migrated user jeane.doe does not point to a known group.
> >> [Tue Jan 26 13:38:02.399703 2016] [:error] [pid 7427]
> >>
> LDAPEntry(ipapython.dn.DN('uid=jeane.doe,cn=users,cn=accounts,dc=example,dc=com'),
> >> {u'mailQuotaSize': ['1024000'], u'cn': ['DOE'], u'uid': [u'jeane.doe'],
> >> u'objectClass': [u'ipaobject', u'organizationalperson', u'qmailuser',
> >> u'top', u'ipasshuser', u'inetorgperson', u'person',
> u'krbticketpolicyaux',
> >> u'krbprincipalaux', u'shadowaccount', u'qmailUser', u'inetuser',
> >> u'posixaccount'], u'loginShell': ['/bin/bash'], u'uidNumber': ['1002'],
> >> u'gidNumber': [u'1000'], u'ipauniqueid': ['autogenerate'],
> >> u'krbprincipalname': [u'jeane@example.com'], u'mailMessageStore':
> >> ['/var/vmail/jeane.doe'], u'description': ['__no_upg__'],
> u'displayName':
> >> ['Jeane Doe'], u'userPassword':
> ['{SSHA}+fXBt+2vlneTFUDhnEv9YvHS4Zo65LIT'],
> >> u'accountStatus': ['yes'], u'sn': ['Jeane'], u'homeDirectory':
> >> ['/var/vmail/jeane.doe'], u'mail': ['jeane@example.com'],
> >> u'givenName': ['DOE']})
> >>
> >> Regards.
> >>
> >> 2016-01-26 11:22 GMT+01:00 wodel youchi 

Re: [Freeipa-users] FREAK Vulnerability

[Terry John]

Thanks for this. I've had a look today
We are running:

ipa-server.x86_64 3.0.0-47.el6.centos

and some of the directives did not work, namely  allowWeakCipher, sslVersionMin 
 and sslVersionMax . So I commented them out
The ldapupdater then seems happy but when I went to restart IPA. The ldap 
server wasn't happy with cipher TLS_RSA_WITH_AES_256_CBC_SHA256 and would not 
start.

Now I can't change anything and it doesn't work. Reaching for my backup.

Terry

-Original Message-
From: Christian Heimes [mailto:chei...@redhat.com]
Sent: 22 January 2016 10:03
To: Terry John; Martin Kosek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FREAK Vulnerability

On 2016-01-21 17:54, Terry John wrote:
> Thanks for the info. I have tried nearly all the NSSCipherSuite settings in 
> that ticket but none so far has eliminated the FREAK report.
> Christian thanks for the heads up on the syntax, I wasn't sure of what
> I was doing
>
> Each time I've made a change I've run an sslscan from the OpenVAS scanner and 
> I do get a different result each time but the errors still remains in OpenVAS.
> Aaargh! Just noticed the port is 636/tcp(!) which is ns-slapd.
>
> Back to the drawing board :-)

Hi Terry,

you can give the attached file a try. It's a ldif file for ipa-ldap-updater. 
You need to run the command on the machine as root and restart 389-DS.

The hardened TLS configuration is highly experimental and comes with no 
warranty whatsoever. The configuration works on my tests systems with Python's 
ldap client and Apache Directory Studio. It may not work with other clients, 
especially older clients or clients in FIPS mode.

Christian



The Manheim group of companies within the UK comprises: Manheim Europe Limited 
(registered number: 03183918), Manheim Auctions Limited (registered number: 
00448761), Manheim Retail Services Limited (registered number: 02838588), 
Motors.co.uk Limited (registered number: 05975777), Real Time Communications 
Limited (registered number: 04277845) and Complete Automotive Solutions Limited 
(registered number: 05302535). Each of these companies is registered in England 
and Wales with the registered office address of Central House, Leeds Road, 
Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various 
brand/trading names including Manheim Inspection Services, Manheim Auctions, 
Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions.

V:0CF72C13B2AC



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

Re: [Freeipa-users] FREAK Vulnerability

[Martin Basti]

On 26.01.2016 17:39, Terry John wrote:

Thanks for this. I've had a look today
We are running:

ipa-server.x86_64 3.0.0-47.el6.centos

and some of the directives did not work, namely  allowWeakCipher, sslVersionMin 
 and sslVersionMax . So I commented them out
The ldapupdater then seems happy but when I went to restart IPA. The ldap 
server wasn't happy with cipher TLS_RSA_WITH_AES_256_CBC_SHA256 and would not 
start.

Now I can't change anything and it doesn't work. Reaching for my backup.

IMO you can manually change dse.ldif, remove cipher from there and start DS
the file should be in /etc/dirsrv/slapd-/|instance_name|/


Terry

-Original Message-
From: Christian Heimes [mailto:chei...@redhat.com]
Sent: 22 January 2016 10:03
To: Terry John; Martin Kosek; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FREAK Vulnerability

On 2016-01-21 17:54, Terry John wrote:

Thanks for the info. I have tried nearly all the NSSCipherSuite settings in 
that ticket but none so far has eliminated the FREAK report.
Christian thanks for the heads up on the syntax, I wasn't sure of what
I was doing

Each time I've made a change I've run an sslscan from the OpenVAS scanner and I 
do get a different result each time but the errors still remains in OpenVAS.
Aaargh! Just noticed the port is 636/tcp(!) which is ns-slapd.

Back to the drawing board :-)

Hi Terry,

you can give the attached file a try. It's a ldif file for ipa-ldap-updater. 
You need to run the command on the machine as root and restart 389-DS.

The hardened TLS configuration is highly experimental and comes with no 
warranty whatsoever. The configuration works on my tests systems with Python's 
ldap client and Apache Directory Studio. It may not work with other clients, 
especially older clients or clients in FIPS mode.

Christian



The Manheim group of companies within the UK comprises: Manheim Europe Limited 
(registered number: 03183918), Manheim Auctions Limited (registered number: 
00448761), Manheim Retail Services Limited (registered number: 02838588), 
Motors.co.uk Limited (registered number: 05975777), Real Time Communications 
Limited (registered number: 04277845) and Complete Automotive Solutions Limited 
(registered number: 05302535). Each of these companies is registered in England 
and Wales with the registered office address of Central House, Leeds Road, 
Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various 
brand/trading names including Manheim Inspection Services, Manheim Auctions, 
Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions.

V:0CF72C13B2AC





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

Re: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Ash Alam]

thank you! Out of curiosity has anyone been able to automate this using
chef/puppet etc?

On Tue, Jan 26, 2016 at 10:56 AM, Martin Kosek  wrote:

> Did you follow the instructions in the error message? There is also a
> longer
> description here:
>
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
>
> Martin
>
> On 01/26/2016 04:38 PM, Ash Alam wrote:
> > I wanted to follow up on this as i finally gotten around to doing the
> > upgrade. I an running into this error. I also found a bugzilla ticket. Do
> > you have to do some type of schema upgrade like you do with active
> > directory?
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1235766
> >
> > STDERR: ipa : CRITICAL The master CA directory server does
> not
> > have necessary schema. Please copy the following script to all CA masters
> > and run it on them: /usr/share/ipa/copy-schema-to-ca.py
> >
> > If you are certain that this is a false positive, use
> > --skip-schema-check.
> >
> > ipa.ipapython.install.cli.install_tool(Replica): ERRORIPA schema
> > missing on master CA directory server
> >
> >
> >
> > Thank You
> >
> >
> >
> >
> > On Fri, Nov 20, 2015 at 11:13 AM, Martin Kosek 
> wrote:
> >
> >> On 11/20/2015 04:08 PM, Ash Alam wrote:
> >>
> >>> Most of the clients in my env are centos 6.6 with ipa 3.0.0 client
> >>> installed. I
> >>> if bring up a replica on centos 7.2 with ipa 4.2.3 server and then
> start
> >>> phasing out the older 3.0.0 servers. Will the client that are still
> >>> running the
> >>> older client software still work?
> >>>
> >>
> >> It should, yes. It is expected that there are RHEL/CentOS-6 clients with
> >> RHEL-7 FreeIPA servers. The older clients just won't be able to use the
> >> newest features.
> >>
> >>
> >>> On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek  >>> > wrote:
> >>>
> >>> On 11/19/2015 11:03 PM, Ash Alam wrote:
> >>>
> >>> Hello All
> >>>
> >>> I am looking for some advice on upgrading. Currently our
> FreeIPA
> >>> servers are
> >>> 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7.
> This
> >>> upgrade path
> >>> is not possible per IPA documentation. Minimum version required
> >>> is 3.3.x. I
> >>> have also found that cenos6 does not provide anything past
> 3.0.0.
> >>>
> >>>
> >>> And it won't. There are no plans in updating FreeIPA version in
> >>> RHEL/CentOS-6.x, we encourage people who want the new features to
> >>> migrate
> >>> to RHEL-7.x:
> >>>
> >>>
> >>>
> http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS
> >>>
> >>>
> >>>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
> >>>
> >>> If you want to wait on CentOS-7.2, it should be in works now:
> >>> http://seven.centos.org/2015/11/rhel-7-2-released-today/
> >>>
> >>> One idea is to upgrade to 3.3.x first and then upgrade to 4.2.3
> >>> on centos7.
> >>> This is harder since centos does not provide this. The other
> >>> issue is if
> >>> 3.0/3.3 client will be supported with 4.2.3 server.
> >>>
> >>>
> >>> The right way is to migrate via creating replicas in
> RHEL/CentOS-7.x
> >>> and
> >>> slowly deprecating RHEL/CentOS-6 ones. Detailed procedure in the
> >>> links above.
> >>>
> >>>
> >>>
> >>
> >
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FREAK Vulnerability

[Rich Megginson]

On 01/26/2016 10:00 AM, Martin Basti wrote:



On 26.01.2016 17:39, Terry John wrote:

Thanks for this. I've had a look today
We are running:

ipa-server.x86_64 3.0.0-47.el6.centos

and some of the directives did not work, namely  allowWeakCipher, sslVersionMin 
 and sslVersionMax . So I commented them out
The ldapupdater then seems happy but when I went to restart IPA. The ldap 
server wasn't happy with cipher TLS_RSA_WITH_AES_256_CBC_SHA256 and would not 
start.

Now I can't change anything and it doesn't work. Reaching for my backup.
IMO you can manually change dse.ldif, remove cipher from there and 
start DS

the file should be in /etc/dirsrv/slapd-/|instance_name|/


Make sure slapd is completely shutdown before you edit dse.ldif, or your 
changes will be wiped out.



Terry

-Original Message-
From: Christian Heimes [mailto:chei...@redhat.com]
Sent: 22 January 2016 10:03
To: Terry John; Martin Kosek;freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FREAK Vulnerability

On 2016-01-21 17:54, Terry John wrote:

Thanks for the info. I have tried nearly all the NSSCipherSuite settings in 
that ticket but none so far has eliminated the FREAK report.
Christian thanks for the heads up on the syntax, I wasn't sure of what
I was doing

Each time I've made a change I've run an sslscan from the OpenVAS scanner and I 
do get a different result each time but the errors still remains in OpenVAS.
Aaargh! Just noticed the port is 636/tcp(!) which is ns-slapd.

Back to the drawing board :-)

Hi Terry,

you can give the attached file a try. It's a ldif file for ipa-ldap-updater. 
You need to run the command on the machine as root and restart 389-DS.

The hardened TLS configuration is highly experimental and comes with no 
warranty whatsoever. The configuration works on my tests systems with Python's 
ldap client and Apache Directory Studio. It may not work with other clients, 
especially older clients or clients in FIPS mode.

Christian



The Manheim group of companies within the UK comprises: Manheim Europe Limited 
(registered number: 03183918), Manheim Auctions Limited (registered number: 
00448761), Manheim Retail Services Limited (registered number: 02838588), 
Motors.co.uk Limited (registered number: 05975777), Real Time Communications 
Limited (registered number: 04277845) and Complete Automotive Solutions Limited 
(registered number: 05302535). Each of these companies is registered in England 
and Wales with the registered office address of Central House, Leeds Road, 
Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various 
brand/trading names including Manheim Inspection Services, Manheim Auctions, 
Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions.

V:0CF72C13B2AC









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

Re: [Freeipa-users] Master Error with two Master CentOS 7.2

[Günther J . Niederwimmer]

Am Dienstag, 26. Januar 2016, 17:13:03 CET schrieb Ludwig Krispenz:
Hello Ludwig,
 
> you got a replicaid (97) leftover form the previous install for the
> o=ipaca backend. The other backend is ok, ipa-replica-manage del did the
> cleanup, but ipa-csreplica-manage doesn't. So you have to clean it
> manually by an ldap command.
:-(
 
> Execute the following mod on one of the servers:
> 
> ldapmodify -D "cn=directory manager" -W -a
> dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
> objectclass: extensibleObject
> replica-base-dn: o=ipaca
> replica-id: 97
> cn: clean 97

Thanks for the Help but  

I copy all in one line but something is wrong with this mod,  i have only the 
Help screen with the parameters ?
 
> On 01/26/2016 04:52 PM, Günther J. Niederwimmer wrote:
> > Am Dienstag, 26. Januar 2016, 14:48:31 CET schrieb Ludwig Krispenz:
> >> On 01/26/2016 12:30 PM, Günther J. Niederwimmer wrote:
> >>> Am Dienstag, 26. Januar 2016, 11:03:27 CET schrieb Ludwig Krispenz:
>  On 01/26/2016 09:45 AM, Günther J. Niederwimmer wrote:
> > I set up a CentOS 7.2 System with two master Server now I found this
> > 1000
> > x
> > Error on my first master?
> > 
> > attrlist_replace - attr_replace (nsslapd-referral,
> > ldap://ipa1.xxx.at:389/ o%3Dipaca) failed.
>  
>  did you install and reinstall the replica on the same machine ? The
>  message is usually related to removed replicaid, which was not properly
>  cleaned.
> >>> 
> >>> Yes, I must delete and reinstall the Replica but I have all cleanup I
> >>> found in the DOC
> >>> 
> >>> ipa-replica-manage del ipa1..at
> >>> ipa-csreplica-manage del ipa1...at
> >>> 
> >>> and create a new
> >>> 
> >>> ipa-replica-prepare ipa1.xxx.at
> >>> 
> >>> the system for ipa1 is a new installed KVM guest., with the same name
> >>> ipa1..at
> >>> 
>  can you do some searches ?. On both masters check which is the
>  replicaID
>  in use and which are the known ruvs:
>  ldapsearch -b "cn=config"  "objectclass=nsds5replica" replicaid
>  nsds50ruv
> >>> 
> >>> Please can you give me the full command I am not a professional  for
> >>> LDAP
> >> 
> >> ldapsearch -LLL -o ldif-wrap=no -x -h  -p 389  -D "cn=directory
> >> manager" -W -b "cn=config" "objectclass=nsds5replica" nsds5replicaid
> >> nsds50ruv
> >> 
> >> for host insert your masters
> > 
> > Thanks for the help.
> > 
> > The original master
> > 
> > dn: cn=replica,cn=dc\3Desslmaier\2Cdc\3Dat,cn=mapping tree,cn=config
> > nsds5replicaid: 4
> > nsds50ruv: {replicageneration} 562f579c0004
> > nsds50ruv: {replica 4 ldap://ipa.esslmaier.at:389} 562f57b70004
> > 56a792640004
> > nsds50ruv: {replica 5 ldap://ipa1.esslmaier.at:389} 568a1fa20005
> > 56a5cf7300020005
> > 
> > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
> > nsds5replicaid: 96
> > nsds50ruv: {replicageneration} 562f57e30060
> > nsds50ruv: {replica 96 ldap://ipa.esslmaier.at:389} 562f58040060
> > 56a790210060
> > nsds50ruv: {replica 91 ldap://ipa1.esslmaier.at:389} 568a1ff7005b
> > 568a20250006005b
> > nsds50ruv: {replica 97 ldap://ipa1.esslmaier.at:389} 562f58110061
> > 5630a9c40061
> > 
> > The first replica master.
> > 
> > nsds5replicaid: 5
> > nsds50ruv: {replicageneration} 562f579c0004
> > nsds50ruv: {replica 5 ldap://ipa1.esslmaier.at:389} 568a1fa20005
> > 56a793fc0005
> > nsds50ruv: {replica 4 ldap://ipa.esslmaier.at:389} 562f57b70004
> > 56a792640004
> > 
> > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
> > nsds5replicaid: 91
> > nsds50ruv: {replicageneration} 562f57e30060
> > nsds50ruv: {replica 91 ldap://ipa1.esslmaier.at:389} 568a1ff7005b
> > 568a20250006005b
> > nsds50ruv: {replica 96 ldap://ipa.esslmaier.at:389} 562f58040060
> > 56a793a50060
> > nsds50ruv: {replica 97 ldap://ipa1.esslmaier.at:389} 562f58110061
> > 5630a9c40061
> > 
> > Is this a bad Error ?
> > 
> > Can I do anything
> > 
> > Thanks for a answer,


-- 
mit freundlichen Grüßen / best regards,

  Günther J. Niederwimmer

-- 
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] Master Error with two Master CentOS 7.2

[Rob Crittenden]

Günther J. Niederwimmer wrote:
> Am Dienstag, 26. Januar 2016, 17:13:03 CET schrieb Ludwig Krispenz:
> Hello Ludwig,
>  
>> you got a replicaid (97) leftover form the previous install for the
>> o=ipaca backend. The other backend is ok, ipa-replica-manage del did the
>> cleanup, but ipa-csreplica-manage doesn't. So you have to clean it
>> manually by an ldap command.
> :-(
>  
>> Execute the following mod on one of the servers:
>>
>> ldapmodify -D "cn=directory manager" -W -a
>> dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
>> objectclass: extensibleObject
>> replica-base-dn: o=ipaca
>> replica-id: 97
>> cn: clean 97
> 
> Thanks for the Help but  
> 
> I copy all in one line but something is wrong with this mod,  i have only the 
> Help screen with the parameters ?

Add -x after ldapmodify.

After the last line put in an extra linefeed then ctrl-D to submit the
request.

rob

>  
>> On 01/26/2016 04:52 PM, Günther J. Niederwimmer wrote:
>>> Am Dienstag, 26. Januar 2016, 14:48:31 CET schrieb Ludwig Krispenz:
 On 01/26/2016 12:30 PM, Günther J. Niederwimmer wrote:
> Am Dienstag, 26. Januar 2016, 11:03:27 CET schrieb Ludwig Krispenz:
>> On 01/26/2016 09:45 AM, Günther J. Niederwimmer wrote:
>>> I set up a CentOS 7.2 System with two master Server now I found this
>>> 1000
>>> x
>>> Error on my first master?
>>>
>>> attrlist_replace - attr_replace (nsslapd-referral,
>>> ldap://ipa1.xxx.at:389/ o%3Dipaca) failed.
>>
>> did you install and reinstall the replica on the same machine ? The
>> message is usually related to removed replicaid, which was not properly
>> cleaned.
>
> Yes, I must delete and reinstall the Replica but I have all cleanup I
> found in the DOC
>
> ipa-replica-manage del ipa1..at
> ipa-csreplica-manage del ipa1...at
>
> and create a new
>
> ipa-replica-prepare ipa1.xxx.at
>
> the system for ipa1 is a new installed KVM guest., with the same name
> ipa1..at
>
>> can you do some searches ?. On both masters check which is the
>> replicaID
>> in use and which are the known ruvs:
>> ldapsearch -b "cn=config"  "objectclass=nsds5replica" replicaid
>> nsds50ruv
>
> Please can you give me the full command I am not a professional  for
> LDAP

 ldapsearch -LLL -o ldif-wrap=no -x -h  -p 389  -D "cn=directory
 manager" -W -b "cn=config" "objectclass=nsds5replica" nsds5replicaid
 nsds50ruv

 for host insert your masters
>>>
>>> Thanks for the help.
>>>
>>> The original master
>>>
>>> dn: cn=replica,cn=dc\3Desslmaier\2Cdc\3Dat,cn=mapping tree,cn=config
>>> nsds5replicaid: 4
>>> nsds50ruv: {replicageneration} 562f579c0004
>>> nsds50ruv: {replica 4 ldap://ipa.esslmaier.at:389} 562f57b70004
>>> 56a792640004
>>> nsds50ruv: {replica 5 ldap://ipa1.esslmaier.at:389} 568a1fa20005
>>> 56a5cf7300020005
>>>
>>> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
>>> nsds5replicaid: 96
>>> nsds50ruv: {replicageneration} 562f57e30060
>>> nsds50ruv: {replica 96 ldap://ipa.esslmaier.at:389} 562f58040060
>>> 56a790210060
>>> nsds50ruv: {replica 91 ldap://ipa1.esslmaier.at:389} 568a1ff7005b
>>> 568a20250006005b
>>> nsds50ruv: {replica 97 ldap://ipa1.esslmaier.at:389} 562f58110061
>>> 5630a9c40061
>>>
>>> The first replica master.
>>>
>>> nsds5replicaid: 5
>>> nsds50ruv: {replicageneration} 562f579c0004
>>> nsds50ruv: {replica 5 ldap://ipa1.esslmaier.at:389} 568a1fa20005
>>> 56a793fc0005
>>> nsds50ruv: {replica 4 ldap://ipa.esslmaier.at:389} 562f57b70004
>>> 56a792640004
>>>
>>> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
>>> nsds5replicaid: 91
>>> nsds50ruv: {replicageneration} 562f57e30060
>>> nsds50ruv: {replica 91 ldap://ipa1.esslmaier.at:389} 568a1ff7005b
>>> 568a20250006005b
>>> nsds50ruv: {replica 96 ldap://ipa.esslmaier.at:389} 562f58040060
>>> 56a793a50060
>>> nsds50ruv: {replica 97 ldap://ipa1.esslmaier.at:389} 562f58110061
>>> 5630a9c40061
>>>
>>> Is this a bad Error ?
>>>
>>> Can I do anything
>>>
>>> Thanks for a answer,
> 
> 

-- 
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] Problem adding user

[Birnbaum, Warren (ETW)]

Hello,

I am trying to add a user into FreeIPA that already exists in /etc/passwd.  How 
can I add him into FreeIPA and employ all the functionality?

Thanks,

Warren

-- 
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] Problem adding user

[Rob Crittenden]

Birnbaum, Warren (ETW) wrote:
> Hello,
> 
> I am trying to add a user into FreeIPA that already exists in
> /etc/passwd.  How can I add him into FreeIPA and employ all the
> functionality?

What is your goal in keeping the user in both systems?

rob

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

Re: [Freeipa-users] Problem adding user

[Birnbaum, Warren (ETW)]

The users I have are authenticated off Active Directory.  I can remove the
user from /etc/passwd but don¹t know how to have the user still be
authenticated from Active Directory instead of I believe Kerberos.  Does
that make any sense?

Thanks,
___
Warren Birnbaum : Infrastructure Services
Web Automation Engineer
Europe CDT Techn. Operations
Nike Inc. : Mobile +31 6 23902697






On 1/26/16, 11:06 AM, "Rob Crittenden"  wrote:

>Birnbaum, Warren (ETW) wrote:
>> Hello,
>> 
>> I am trying to add a user into FreeIPA that already exists in
>> /etc/passwd.  How can I add him into FreeIPA and employ all the
>> functionality?
>
>What is your goal in keeping the user in both systems?
>
>rob
>


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

Re: [Freeipa-users] Master Error with two Master CentOS 7.2

[Lukas Slebodnik]

On (26/01/16 12:47), Rob Crittenden wrote:
>Günther J. Niederwimmer wrote:
>> Am Dienstag, 26. Januar 2016, 17:13:03 CET schrieb Ludwig Krispenz:
>> Hello Ludwig,
>>  
>>> you got a replicaid (97) leftover form the previous install for the
>>> o=ipaca backend. The other backend is ok, ipa-replica-manage del did the
>>> cleanup, but ipa-csreplica-manage doesn't. So you have to clean it
>>> manually by an ldap command.
>> :-(
>>  
>>> Execute the following mod on one of the servers:
>>>
>>> ldapmodify -D "cn=directory manager" -W -a
>>> dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
>>> objectclass: extensibleObject
>>> replica-base-dn: o=ipaca
>>> replica-id: 97
>>> cn: clean 97
>> 
>> Thanks for the Help but  
>> 
>> I copy all in one line but something is wrong with this mod,  i have only 
>> the 
>> Help screen with the parameters ?
>
>Add -x after ldapmodify.
>
>After the last line put in an extra linefeed then ctrl-D to submit the
>request.
>
LDIF does not look like for ldapmodify.
should it have been a ldapadd?

LS

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

Re: [Freeipa-users] Master Error with two Master CentOS 7.2

[Rob Crittenden]

Lukas Slebodnik wrote:
> On (26/01/16 12:47), Rob Crittenden wrote:
>> Günther J. Niederwimmer wrote:
>>> Am Dienstag, 26. Januar 2016, 17:13:03 CET schrieb Ludwig Krispenz:
>>> Hello Ludwig,
>>>  
 you got a replicaid (97) leftover form the previous install for the
 o=ipaca backend. The other backend is ok, ipa-replica-manage del did the
 cleanup, but ipa-csreplica-manage doesn't. So you have to clean it
 manually by an ldap command.
>>> :-(
>>>  
 Execute the following mod on one of the servers:

 ldapmodify -D "cn=directory manager" -W -a
 dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
 objectclass: extensibleObject
 replica-base-dn: o=ipaca
 replica-id: 97
 cn: clean 97
>>>
>>> Thanks for the Help but  
>>>
>>> I copy all in one line but something is wrong with this mod,  i have only 
>>> the 
>>> Help screen with the parameters ?
>>
>> Add -x after ldapmodify.
>>
>> After the last line put in an extra linefeed then ctrl-D to submit the
>> request.
>>
> LDIF does not look like for ldapmodify.
> should it have been a ldapadd?

The -a tells ldapmodify to assume add.

rob

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

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Nathan Peters]

After some more investigation, it appears that there may be more ACIs missing.

I added the missing permission (System: Read Replication Agreements) on all my 
masters, and then the installation failed at this point :
---
[28/43]: setting up initial replication
Starting replication, please wait until this has completed.
  [error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' privilege to the 
'nsds5BeginReplicaRefresh' attribute of entry 
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping
 tree,cn=config'.\n", 'desc': 'Insufficient access'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROR{'info': 
"Insufficient 'write' privilege to the 'nsds5BeginReplicaRefresh' attribute of 
entry 
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping
 tree,cn=config'.\n", 'desc': 'Insufficient access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
more information

Because of that and a comparison of my earlier version of ldif files from 
earlier versions of FreeIPA, I noticed the following ACI also missing from the 
mapping tree :
--
# dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config
dn: cn=dc\3Dipatestdomain\2Cdc\3Dnet,cn=mapping tree,cn=config
aci: (targetattr=*)(version 3.0;acl "permission:Add Replication Agreements";al
 low (add) groupdn = "ldap:///cn=Add Replication Agreements,cn=permissions,cn=
 pbac,dc=mydomain,dc=net";)
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd
 s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
 ass=nsMappingTree))")(version 3.0; acl "permission:Modify Replication Agreeme
 nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify Replication Ag
 reements,cn=permissions,cn=pbac,dc=mydomain,dc=net";)

After I added that, I attempted my replica installation again this time it 
failed on the o=ipaca branch

Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 
seconds
  [1/23]: creating certificate server user
  [2/23]: creating certificate server db
  [3/23]: setting up initial replication
  [error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' privilege to the 
'nsDS5ReplicaBindDN' attribute of entry 'cn=replica,cn=o\\3dipaca,cn=mapping 
tree,cn=config'.\n", 'desc': 'Insufficient access'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROR{'info': 
"Insufficient 'write' privilege to the 'nsDS5ReplicaBindDN' attribute of entry 
'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n", 'desc': 'Insufficient 
access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
more information

Looking at that branch of the ldap tree, I noticed some differences
---
In the cn=yourdomain,cn=mapping tree,cn=config you will find the following 
permissions :
permission:Add Replication Agreements
In the cn=o=ipaca,cn=mapping tree,cn=config you will find the following 
permissions :
cert manager: Add Replication Agreements

=
So I think there are actually 3 issues :
===
1. Missing aci on base cn=config entry
2. Missing aci on dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config branch
3. acis are on the o=ipaca branch, but they are wrong as they only apply to 
cert manager, and not all users

-Original Message-
From: Martin Basti [mailto:mba...@redhat.com] 
Sent: January-25-16 4:57 AM
To: Nathan Peters; Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with 
DuplicateEntry: This entry already exists

Thank you,

I found root cause why "System: Read Replication Agreements" ACI is not on 
replica.

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

I have to figure out why this permission is added on centos7.2, because IMO 
this bug is there from 4.0.


On 24.01.2016 03:22, Nathan Peters wrote:
> I can now confirm that this is a 100% reproducible bug, and a pretty severe 
> one at that.  You should be able to reproduce this issue at will if you 
> follow these steps.  It may actually be possible with less servers and less 
> steps, but here is what I did in a test lab today:
>
> 1. Create a brand new FreeIPA domain in CentOS 7.2 / FreeIPA 4.2.0 with 3 
> servers, dc1, dc2, dc3, replicating any way you want.
> 3. Use ipa-replica-manage del dc2.ipatestdomain.net, and then delete the 
> server / vm / whatever you have it running on
> 3. Install Fedora 23 on the same IP address 

Re: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Ash Alam]

I didnt want to dig up an old thread but i am running into this issue. The
old thread points to Pki 10.2.6 as the solution but i am not seeing that
package on centos 7.2.

STDERR: ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to
configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f'
'/tmp/tmpHfdvFD'' returned non-zero exit status 1


Thank You


On Tue, Jan 26, 2016 at 12:14 PM, Ash Alam  wrote:

> thank you! Out of curiosity has anyone been able to automate this using
> chef/puppet etc?
>
> On Tue, Jan 26, 2016 at 10:56 AM, Martin Kosek  wrote:
>
>> Did you follow the instructions in the error message? There is also a
>> longer
>> description here:
>>
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
>>
>> Martin
>>
>> On 01/26/2016 04:38 PM, Ash Alam wrote:
>> > I wanted to follow up on this as i finally gotten around to doing the
>> > upgrade. I an running into this error. I also found a bugzilla ticket.
>> Do
>> > you have to do some type of schema upgrade like you do with active
>> > directory?
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1235766
>> >
>> > STDERR: ipa : CRITICAL The master CA directory server does
>> not
>> > have necessary schema. Please copy the following script to all CA
>> masters
>> > and run it on them: /usr/share/ipa/copy-schema-to-ca.py
>> >
>> > If you are certain that this is a false positive, use
>> > --skip-schema-check.
>> >
>> > ipa.ipapython.install.cli.install_tool(Replica): ERRORIPA schema
>> > missing on master CA directory server
>> >
>> >
>> >
>> > Thank You
>> >
>> >
>> >
>> >
>> > On Fri, Nov 20, 2015 at 11:13 AM, Martin Kosek 
>> wrote:
>> >
>> >> On 11/20/2015 04:08 PM, Ash Alam wrote:
>> >>
>> >>> Most of the clients in my env are centos 6.6 with ipa 3.0.0 client
>> >>> installed. I
>> >>> if bring up a replica on centos 7.2 with ipa 4.2.3 server and then
>> start
>> >>> phasing out the older 3.0.0 servers. Will the client that are still
>> >>> running the
>> >>> older client software still work?
>> >>>
>> >>
>> >> It should, yes. It is expected that there are RHEL/CentOS-6 clients
>> with
>> >> RHEL-7 FreeIPA servers. The older clients just won't be able to use the
>> >> newest features.
>> >>
>> >>
>> >>> On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek > >>> > wrote:
>> >>>
>> >>> On 11/19/2015 11:03 PM, Ash Alam wrote:
>> >>>
>> >>> Hello All
>> >>>
>> >>> I am looking for some advice on upgrading. Currently our
>> FreeIPA
>> >>> servers are
>> >>> 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7.
>> This
>> >>> upgrade path
>> >>> is not possible per IPA documentation. Minimum version
>> required
>> >>> is 3.3.x. I
>> >>> have also found that cenos6 does not provide anything past
>> 3.0.0.
>> >>>
>> >>>
>> >>> And it won't. There are no plans in updating FreeIPA version in
>> >>> RHEL/CentOS-6.x, we encourage people who want the new features to
>> >>> migrate
>> >>> to RHEL-7.x:
>> >>>
>> >>>
>> >>>
>> http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS
>> >>>
>> >>>
>> >>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
>> >>>
>> >>> If you want to wait on CentOS-7.2, it should be in works now:
>> >>> http://seven.centos.org/2015/11/rhel-7-2-released-today/
>> >>>
>> >>> One idea is to upgrade to 3.3.x first and then upgrade to
>> 4.2.3
>> >>> on centos7.
>> >>> This is harder since centos does not provide this. The other
>> >>> issue is if
>> >>> 3.0/3.3 client will be supported with 4.2.3 server.
>> >>>
>> >>>
>> >>> The right way is to migrate via creating replicas in
>> RHEL/CentOS-7.x
>> >>> and
>> >>> slowly deprecating RHEL/CentOS-6 ones. Detailed procedure in the
>> >>> links above.
>> >>>
>> >>>
>> >>>
>> >>
>> >
>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Martin Basti]

On 26.01.2016 21:03, Nathan Peters wrote:

After some more investigation, it appears that there may be more ACIs missing.

I added the missing permission (System: Read Replication Agreements) on all my 
masters, and then the installation failed at this point :
---
[28/43]: setting up initial replication
Starting replication, please wait until this has completed.
   [error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' privilege to the 
'nsds5BeginReplicaRefresh' attribute of entry 
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping 
tree,cn=config'.\n", 'desc': 'Insufficient access'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROR{'info': "Insufficient 
'write' privilege to the 'nsds5BeginReplicaRefresh' attribute of entry 
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping 
tree,cn=config'.\n", 'desc': 'Insufficient access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
more information

Because of that and a comparison of my earlier version of ldif files from 
earlier versions of FreeIPA, I noticed the following ACI also missing from the 
mapping tree :
--
# dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config
dn: cn=dc\3Dipatestdomain\2Cdc\3Dnet,cn=mapping tree,cn=config
aci: (targetattr=*)(version 3.0;acl "permission:Add Replication Agreements";al
  low (add) groupdn = "ldap:///cn=Add Replication Agreements,cn=permissions,cn=
  pbac,dc=mydomain,dc=net";)
aci: (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd
  s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
  ass=nsMappingTree))")(version 3.0; acl "permission:Modify Replication Agreeme
  nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify Replication Ag
  reements,cn=permissions,cn=pbac,dc=mydomain,dc=net";)

After I added that, I attempted my replica installation again this time it 
failed on the o=ipaca branch

Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 
seconds
   [1/23]: creating certificate server user
   [2/23]: creating certificate server db
   [3/23]: setting up initial replication
   [error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' privilege to the 
'nsDS5ReplicaBindDN' attribute of entry 'cn=replica,cn=o\\3dipaca,cn=mapping 
tree,cn=config'.\n", 'desc': 'Insufficient access'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROR{'info': "Insufficient 
'write' privilege to the 'nsDS5ReplicaBindDN' attribute of entry 
'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n", 'desc': 'Insufficient 
access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
ipa-replica-install command failed. See /var/log/ipareplica-install.log for 
more information

Looking at that branch of the ldap tree, I noticed some differences
---
In the cn=yourdomain,cn=mapping tree,cn=config you will find the following 
permissions :
permission:Add Replication Agreements
In the cn=o=ipaca,cn=mapping tree,cn=config you will find the following 
permissions :
cert manager: Add Replication Agreements

=
So I think there are actually 3 issues :
===
1. Missing aci on base cn=config entry
2. Missing aci on dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config branch
3. acis are on the o=ipaca branch, but they are wrong as they only apply to 
cert manager, and not all users

I'm not sure if this covers your issues, but it may be related

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

Martin


-Original Message-
From: Martin Basti [mailto:mba...@redhat.com]
Sent: January-25-16 4:57 AM
To: Nathan Peters; Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with 
DuplicateEntry: This entry already exists

Thank you,

I found root cause why "System: Read Replication Agreements" ACI is not on 
replica.

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

I have to figure out why this permission is added on centos7.2, because IMO 
this bug is there from 4.0.


On 24.01.2016 03:22, Nathan Peters wrote:

I can now confirm that this is a 100% reproducible bug, and a pretty severe one 
at that.  You should be able to reproduce this issue at will if you follow 
these steps.  It may actually be possible with less servers and less steps, but 
here is what I did in a test lab today:

1. Create a brand new FreeIPA domain in CentOS 7.2 / FreeIPA 4.2.0 with 3 
servers, dc1, dc2, dc3, replicating any way you want.
3. Use 

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Martin Basti]

On 26.01.2016 21:51, Martin Basti wrote:



On 26.01.2016 21:03, Nathan Peters wrote:
After some more investigation, it appears that there may be more ACIs 
missing.


I added the missing permission (System: Read Replication Agreements) 
on all my masters, and then the installation failed at this point :

---
[28/43]: setting up initial replication
Starting replication, please wait until this has completed.
   [error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' 
privilege to the 'nsds5BeginReplicaRefresh' attribute of entry 
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping 
tree,cn=config'.\n", 'desc': 'Insufficient access'}

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROR {'info': 
"Insufficient 'write' privilege to the 'nsds5BeginReplicaRefresh' 
attribute of entry 
'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2cdc\\3dnet,cn=mapping 
tree,cn=config'.\n", 'desc': 'Insufficient access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
ipa-replica-install command failed. See 
/var/log/ipareplica-install.log for more information


Because of that and a comparison of my earlier version of ldif files 
from earlier versions of FreeIPA, I noticed the following ACI also 
missing from the mapping tree :

--
# dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config
dn: cn=dc\3Dipatestdomain\2Cdc\3Dnet,cn=mapping tree,cn=config
aci: (targetattr=*)(version 3.0;acl "permission:Add Replication 
Agreements";al
  low (add) groupdn = "ldap:///cn=Add Replication 
Agreements,cn=permissions,cn=

  pbac,dc=mydomain,dc=net";)
aci: 
(targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass=nsd

s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
  ass=nsMappingTree))")(version 3.0; acl "permission:Modify 
Replication Agreeme
  nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify 
Replication Ag

  reements,cn=permissions,cn=pbac,dc=mydomain,dc=net";)

After I added that, I attempted my replica installation again this 
time it failed on the o=ipaca branch


Configuring certificate server (pki-tomcatd). Estimated time: 3 
minutes 30 seconds

   [1/23]: creating certificate server user
   [2/23]: creating certificate server db
   [3/23]: setting up initial replication
   [error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' 
privilege to the 'nsDS5ReplicaBindDN' attribute of entry 
'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n", 'desc': 
'Insufficient access'}

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROR {'info': 
"Insufficient 'write' privilege to the 'nsDS5ReplicaBindDN' attribute 
of entry 'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n", 
'desc': 'Insufficient access'}
ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
ipa-replica-install command failed. See 
/var/log/ipareplica-install.log for more information


Looking at that branch of the ldap tree, I noticed some differences
--- 

In the cn=yourdomain,cn=mapping tree,cn=config you will find the 
following permissions :

permission:Add Replication Agreements
In the cn=o=ipaca,cn=mapping tree,cn=config you will find the 
following permissions :

cert manager: Add Replication Agreements

=
So I think there are actually 3 issues :
===
1. Missing aci on base cn=config entry
2. Missing aci on dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config 
branch
3. acis are on the o=ipaca branch, but they are wrong as they only 
apply to cert manager, and not all users

I'm not sure if this covers your issues, but it may be related

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

Martin


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



-Original Message-
From: Martin Basti [mailto:mba...@redhat.com]
Sent: January-25-16 4:57 AM
To: Nathan Peters; Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails 
with DuplicateEntry: This entry already exists


Thank you,

I found root cause why "System: Read Replication Agreements" ACI is 
not on replica.


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

I have to figure out why this permission is added on centos7.2, 
because IMO this bug is there from 4.0.



On 24.01.2016 03:22, Nathan Peters wrote:
I can now confirm that this is a 100% reproducible bug, and a pretty 
severe one at that.  You should be able to reproduce this issue at 
will if you follow these steps.  It may actually be possible with 
less servers and less steps, but here is what I did in a test lab 
today:


1. Create a 

[Freeipa-users] Client-Install failures

[David Zabner]

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

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



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

Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with DuplicateEntry: This entry already exists

[Nathan Peters]

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

^--- That was the one.  It triggered differently for me because I had manually 
re-replaced the aci in the dc=domain,dc=mapping tree branch.

Had I left it alone it would have triggered exactly as in thebug report.  
However, that bug report did let me know how to fix it.

I made a brand new FreeIPA 4.3.0 domain with a single master (which has the 
correct ACI entries for the mapping tree branch), then copied those ACIs into 
my existing domain (edit dse.ldif when the server is turned off).

I was able to successfully install a replica after that.

Thanks for pointing out the actual bug.  I'm fairly new to debugging 389 DS so 
knowing what branch needed to be fixed was invaluable.


-Original Message-
From: Martin Basti [mailto:mba...@redhat.com] 
Sent: January-26-16 12:57 PM
To: Nathan Peters; Rich Megginson; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa 4.3.0 replica installation fails with 
DuplicateEntry: This entry already exists



On 26.01.2016 21:51, Martin Basti wrote:
>
>
> On 26.01.2016 21:03, Nathan Peters wrote:
>> After some more investigation, it appears that there may be more ACIs 
>> missing.
>>
>> I added the missing permission (System: Read Replication Agreements) 
>> on all my masters, and then the installation failed at this point :
>> ---
>> [28/43]: setting up initial replication Starting replication, please 
>> wait until this has completed.
>>[error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' 
>> privilege to the 'nsds5BeginReplicaRefresh' attribute of entry 
>> 'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2c
>> dc\\3dnet,cn=mapping tree,cn=config'.\n", 'desc': 'Insufficient 
>> access'} Your system may be partly configured.
>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>> ipa.ipapython.install.cli.install_tool(Replica): ERROR {'info': 
>> "Insufficient 'write' privilege to the 'nsds5BeginReplicaRefresh' 
>> attribute of entry
>> 'cn=metodc2-ipa-dev-van.mydomain.net,cn=replica,cn=dc\\3dmydomain\\2c
>> dc\\3dnet,cn=mapping tree,cn=config'.\n", 'desc': 'Insufficient 
>> access'}
>> ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
>> ipa-replica-install command failed. See 
>> /var/log/ipareplica-install.log for more information
>>
>> Because of that and a comparison of my earlier version of ldif files 
>> from earlier versions of FreeIPA, I noticed the following ACI also 
>> missing from the mapping tree :
>> --
>> # dc\3Dipatestdomain\2Cdc\3Dnet, mapping tree, config
>> dn: cn=dc\3Dipatestdomain\2Cdc\3Dnet,cn=mapping tree,cn=config
>> aci: (targetattr=*)(version 3.0;acl "permission:Add Replication 
>> Agreements";al
>>   low (add) groupdn = "ldap:///cn=Add Replication 
>> Agreements,cn=permissions,cn=
>>   pbac,dc=mydomain,dc=net";)
>> aci: 
>> (targetattr=*)(targetfilter="(|(objectclass=nsds5Replica)(objectclass
>> =nsd 
>> s5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectCl
>>   ass=nsMappingTree))")(version 3.0; acl "permission:Modify 
>> Replication Agreeme
>>   nts"; allow (read, write, search) groupdn = "ldap:///cn=Modify 
>> Replication Ag
>>   reements,cn=permissions,cn=pbac,dc=mydomain,dc=net";)
>>
>> After I added that, I attempted my replica installation again this 
>> time it failed on the o=ipaca branch
>> 
>> Configuring certificate server (pki-tomcatd). Estimated time: 3 
>> minutes 30 seconds
>>[1/23]: creating certificate server user
>>[2/23]: creating certificate server db
>>[3/23]: setting up initial replication
>>[error] INSUFFICIENT_ACCESS: {'info': "Insufficient 'write' 
>> privilege to the 'nsDS5ReplicaBindDN' attribute of entry 
>> 'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n", 'desc':
>> 'Insufficient access'}
>> Your system may be partly configured.
>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>> ipa.ipapython.install.cli.install_tool(Replica): ERROR {'info': 
>> "Insufficient 'write' privilege to the 'nsDS5ReplicaBindDN' attribute 
>> of entry 'cn=replica,cn=o\\3dipaca,cn=mapping tree,cn=config'.\n",
>> 'desc': 'Insufficient access'}
>> ipa.ipapython.install.cli.install_tool(Replica): ERRORThe 
>> ipa-replica-install command failed. See 
>> /var/log/ipareplica-install.log for more information
>>
>> Looking at that branch of the ldap tree, I noticed some differences
>> -
>> --
>>
>> In the cn=yourdomain,cn=mapping tree,cn=config you will find the 
>> following permissions :
>> permission:Add Replication Agreements In the cn=o=ipaca,cn=mapping 
>> tree,cn=config you will find the following permissions :
>> cert manager: Add Replication Agreements
>>
>> =
>> So I think there are actually 3 issues :
>> ===
>> 1. Missing aci on base 

[Freeipa-users] ipa-trust and SRV records

[Simpson Lachlan]

At the end of the installation of the ipa-adtrust-install, there is a message 
along the lines of:



Add the following service records to your DNS server for DNS zone 
unix.co.org.au:

 _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs
 _ldap._tcp.dc._msdcs
 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
 _kerberos._tcp.dc._msdcs
 _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs
 _kerberos._udp.dc._msdcs


Which has, I think, been the cause of all of my grief.

Do these SRV records in AD represent the minimum DNS set up required in Active 
Directory (my setup is a one way trust from FreeIPA to an AD over which I have 
no control, and all DNS is passed up to AD)?

These records are required so that the FreeIPA server can find the AD servers? 

Also, is it fair to infer that Default-First-Site-Name is in our case co.org.au?

Cheers
L.
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] Freeipa 4.3.0 : Forward only Policy fails for reverse lookup zones

[Nathan Peters]

I have my FreeIPA server setup with a forward only policy for DNS.

If I perform an nslookup against either of the configured forward servers, I 
can do a reverse lookup properly.

If I perform the same nslookup against my local server, it will not find the 
entry.

I have confirmed that there are no conflicting zones or reverse zones on my 
FreeIPA server.

Tests below :

1.Show forwarding configuration

2.Test lookup against localhost of own domain name (prove we can find 
records we host as primary)

3.Prove we can do forward lookup on the host that we can't reverse lookup on

4.Reverse lookup fails against localhost

5.Reverse lookup succeeds against forward server 1

6.Reverse lookup succeeds against forward server 2

So... if I am set to always forward, and I don't host this domain (or a parent 
of it), and I can lookup the server on my forwarded domains,

Then... why can't that query get forwarded properly according to my forwarding 
settings ?

1. ===
[root@dc2-ipa-dev-van ~]# ipa dnsconfig-show
  Global forwarders: 10.21.0.15, 10.21.0.14
  Forward policy: only
  Allow PTR sync: TRUE
2. ===
  [root@dc2-ipa-dev-van ~]# nslookup
> dc2-ipa-dev-van.dev-mydomain.net
Server: 127.0.0.1
Address:127.0.0.1#53

Name:   dc2-ipa-dev-van.dev-mydomain.net
Address: 10.21.0.98
3. ===
> officedc2.office.mydomain.net
Server: 127.0.0.1
Address:127.0.0.1#53

Non-authoritative answer:
Name:   officedc2.office.mydomain.net
Address: 10.6.60.6
4. ===
> 10.6.60.6
Server: 127.0.0.1
Address:127.0.0.1#53

** server can't find 6.60.6.10.in-addr.arpa: NXDOMAIN
5. ===
> server 10.21.0.14
Default server: 10.21.0.14
Address: 10.21.0.14#53
> 10.6.60.6
Server: 10.21.0.14
Address:10.21.0.14#53

Non-authoritative answer:
6.60.6.10.in-addr.arpa  name = officedc2.office.mydomain.net.

Authoritative answers can be found from:
6. ===
> server 10.21.0.15
Default server: 10.21.0.15
Address: 10.21.0.15#53
> 10.6.60.6
Server: 10.21.0.15
Address:10.21.0.15#53

Non-authoritative answer:
6.60.6.10.in-addr.arpa  name = officedc2.office.mydomain.net.

Authoritative answers can be found from:
>
-- 
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] help

[Tim Moor]

-- 
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] Migration from openLDAP to FreeIPA with qmail.schema

[wodel youchi]

Hi,

I am a newbie in freeipa. I am trying to use it with our mail server.

Our mail server uses openldap with one external schema : qmail.schema, we
use it especially for mailQuota, mailAlternateAddress,
mailForwardingAddress and AccountStatus.

I tried to import this schema to freeipa using ipa-ldap-updater.
I am not sure if I succeeded, but when I tried : ipa config-mod
--addattr=ipaGroupObjectClasses=qmailUser it worked and I can see the
objectClass.


[root@ipamaster work]# ipa config-show --all
  dn: cn=ipaConfig,cn=etc,dc=example,dc=com
  Longueur maximale du nom d'utilisateur: 32
  Base du répertoire utilisateur: /home
  Interprèteur par défaut: /bin/sh
  Groupe utilisateur par défaut: ipausers
  Domaine par défaut pour les courriels: example.com
  Limite de temps d'une recherche: 2
  Limite de taille d'une recherche: 100
  Champs de recherche utilisateur: uid,givenname,sn,telephonenumber,ou,title
  Group search fields: cn,description
  Activer le mode migration: TRUE
  Base de sujet de certificat: O=EXAMPLE.COM
  Classes d'objets de groupe par défaut: top, ipaobject, groupofnames,
ipausergroup, nestedgroup
  Classes d'objets utilisateur par défaut: ipaobject, person, top,
ipasshuser, inetorgperson, organizationalperson,
   krbticketpolicyaux,
krbprincipalaux, *qmailUser*, inetuser, posixaccount
  Notification d'expiration de mot de passe (jours): 4
  Fonctionnalités du greffon mots de passe: AllowNThash
  Ordre de la mappe des utilisateurs SELinux:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
  Utilisateur SELinux par défaut: unconfined_u:s0-s0:c0.c1023
  Types de PAC par défaut: nfs:NONE, MS-PAC
  aci: (targetattr = "cn || createtimestamp || entryusn ||
ipacertificatesubjectbase || ipaconfigstring || ipacustomfields ||
   ipadefaultemaildomain || ipadefaultloginshell ||
ipadefaultprimarygroup || ipagroupobjectclasses ||
   ipagroupsearchfields || ipahomesrootdir || ipakrbauthzdata ||
ipamaxusernamelength || ipamigrationenabled ||
   ipapwdexpadvnotify || ipasearchrecordslimit || ipasearchtimelimit ||
ipaselinuxusermapdefault ||
   ipaselinuxusermaporder || ipauserauthtype || ipauserobjectclasses ||
ipausersearchfields || modifytimestamp ||
   objectclass")(targetfilter = "(objectclass=ipaguiconfig)")(version
3.0;acl "permission:System: Read Global
   Configuration";allow (compare,read,search) userdn = "ldap:///all;;)
  cn: ipaConfig
  objectclass: ipaConfigObject, nsContainer, top, ipaGuiConfig,
ipaUserAuthTypeClass

Then I tried to migrate openldap's accounts, but without luck so far
#ipa -v migrate-ds --with-compat --bind-dn "cn=admin,dc=example,dc=com"
--continue ldap://192.168.1.121:389
---
migrate-ds:
---
Migrated:
Failed user:
  jean.doe: Type or value exists:
  jeane.doe: Type or value exists:
 Failed group:
--
No users/groups were migrated from ldap://192.168.1.121:389


Here is an entry from openldap
dn: uid=jeane.doe,ou=people,dc=example,dc=com
loginShell: /bin/bash
gidNumber: 1000
objectClass: top
objectClass: qmailUser
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: person
objectClass: shadowAccount
objectClass: organizationalPerson
mail: jeane@example.com
givenName: DOE
uid: jeane.doe
uidNumber: 1002
displayName: Jeane Doe
homeDirectory: /var/vmail/jeane.doe
accountStatus: yes
mailMessageStore: /var/vmail/jeane.doe
structuralObjectClass: inetOrgPerson
entryUUID: 3e8ee290-166f-1035-94d7-ef8fa27fbe71
creatorsName: cn=admin,dc=example,dc=com
createTimestamp: 20151103120748Z
userPassword:: e1NTSEF9K2ZYQnQrMnZsbmVURlVEaG5FdjlZdkhTNFpvNjVMSVQ=
mailQuotaSize: 1024000
sn: Jeane
cn: DOE
entryCSN: 20160125162455.613052Z#00#000#00
modifiersName: cn=admin,dc=example,dc=com
modifyTimestamp: 20160125162455Z

What does "Type or value exists" means?

PS: the qmail.schema presents two other objectClasses, but I didn't add use
them (qldapAdmin, qmailGroup)

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

Re: [Freeipa-users] Migration from openLDAP to FreeIPA with qmail.schema

[wodel youchi]

Thanks I will try and report back.

I am using Centos 7.2x64 with latest updates

and ipa-server-4.2.0-15.el7.centos.3.x86_64

Regards

2016-01-26 10:53 GMT+01:00 Martin Kosek :

> On 01/26/2016 10:16 AM, wodel youchi wrote:
> > Hi,
> >
> > I am a newbie in freeipa. I am trying to use it with our mail server.
>
> Cool! What is your version of the FreeIPA server? It will be important for
> further investigation.
>
> > Our mail server uses openldap with one external schema : qmail.schema, we
> > use it especially for mailQuota, mailAlternateAddress,
> > mailForwardingAddress and AccountStatus.
> >
> > I tried to import this schema to freeipa using ipa-ldap-updater.
> > I am not sure if I succeeded, but when I tried : ipa config-mod
> > --addattr=ipaGroupObjectClasses=qmailUser it worked and I can see the
> > objectClass.
> >
> >
> > [root@ipamaster work]# ipa config-show --all
> >   dn: cn=ipaConfig,cn=etc,dc=example,dc=com
> >   Longueur maximale du nom d'utilisateur: 32
> >   Base du répertoire utilisateur: /home
> >   Interprèteur par défaut: /bin/sh
> >   Groupe utilisateur par défaut: ipausers
> >   Domaine par défaut pour les courriels: example.com
> >   Limite de temps d'une recherche: 2
> >   Limite de taille d'une recherche: 100
> >   Champs de recherche utilisateur:
> uid,givenname,sn,telephonenumber,ou,title
> >   Group search fields: cn,description
> >   Activer le mode migration: TRUE
> >   Base de sujet de certificat: O=EXAMPLE.COM
> >   Classes d'objets de groupe par défaut: top, ipaobject, groupofnames,
> > ipausergroup, nestedgroup
> >   Classes d'objets utilisateur par défaut: ipaobject, person, top,
> > ipasshuser, inetorgperson, organizationalperson,
> >krbticketpolicyaux,
> > krbprincipalaux, *qmailUser*, inetuser, posixaccount
> >   Notification d'expiration de mot de passe (jours): 4
> >   Fonctionnalités du greffon mots de passe: AllowNThash
> >   Ordre de la mappe des utilisateurs SELinux:
> >
> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
> >   Utilisateur SELinux par défaut: unconfined_u:s0-s0:c0.c1023
> >   Types de PAC par défaut: nfs:NONE, MS-PAC
> >   aci: (targetattr = "cn || createtimestamp || entryusn ||
> > ipacertificatesubjectbase || ipaconfigstring || ipacustomfields ||
> >ipadefaultemaildomain || ipadefaultloginshell ||
> > ipadefaultprimarygroup || ipagroupobjectclasses ||
> >ipagroupsearchfields || ipahomesrootdir || ipakrbauthzdata ||
> > ipamaxusernamelength || ipamigrationenabled ||
> >ipapwdexpadvnotify || ipasearchrecordslimit || ipasearchtimelimit
> ||
> > ipaselinuxusermapdefault ||
> >ipaselinuxusermaporder || ipauserauthtype || ipauserobjectclasses
> ||
> > ipausersearchfields || modifytimestamp ||
> >objectclass")(targetfilter = "(objectclass=ipaguiconfig)")(version
> > 3.0;acl "permission:System: Read Global
> >Configuration";allow (compare,read,search) userdn =
> "ldap:///all;;)
> >   cn: ipaConfig
> >   objectclass: ipaConfigObject, nsContainer, top, ipaGuiConfig,
> > ipaUserAuthTypeClass
> >
> > Then I tried to migrate openldap's accounts, but without luck so far
> > #ipa -v migrate-ds --with-compat --bind-dn "cn=admin,dc=example,dc=com"
> > --continue ldap://192.168.1.121:389
> > ---
> > migrate-ds:
> > ---
> > Migrated:
> > Failed user:
> >   jean.doe: Type or value exists:
> >   jeane.doe: Type or value exists:
> >  Failed group:
> > --
> > No users/groups were migrated from ldap://192.168.1.121:389
> >
> >
> > Here is an entry from openldap
> > dn: uid=jeane.doe,ou=people,dc=example,dc=com
> > loginShell: /bin/bash
> > gidNumber: 1000
> > objectClass: top
> > objectClass: qmailUser
> > objectClass: inetOrgPerson
> > objectClass: posixAccount
> > objectClass: person
> > objectClass: shadowAccount
> > objectClass: organizationalPerson
> > mail: jeane@example.com
> > givenName: DOE
> > uid: jeane.doe
> > uidNumber: 1002
> > displayName: Jeane Doe
> > homeDirectory: /var/vmail/jeane.doe
> > accountStatus: yes
> > mailMessageStore: /var/vmail/jeane.doe
> > structuralObjectClass: inetOrgPerson
> > entryUUID: 3e8ee290-166f-1035-94d7-ef8fa27fbe71
> > creatorsName: cn=admin,dc=example,dc=com
> > createTimestamp: 20151103120748Z
> > userPassword:: e1NTSEF9K2ZYQnQrMnZsbmVURlVEaG5FdjlZdkhTNFpvNjVMSVQ=
> > mailQuotaSize: 1024000
> > sn: Jeane
> > cn: DOE
> > entryCSN: 20160125162455.613052Z#00#000#00
> > modifiersName: cn=admin,dc=example,dc=com
> > modifyTimestamp: 20160125162455Z
> >
> > What does "Type or value exists" means?
>
> That normally means that you have the same value for LDAP attribute twice
> or
> that you are trying to add multiple values for a single valued attribute. I
> wonder if we could get better logging, like how exactly the entry looks
> like
> before it is added to LDAP.
>
> But right now, I cannot think about a better way than to updating
> 

Re: [Freeipa-users] Migration from openLDAP to FreeIPA with qmail.schema

[wodel youchi]

Hi again,

This is what I get from httpd error_log

[Tue Jan 26 13:38:02.394757 2016] [:error] [pid 7427] ipa: WARNING: GID
number 1000 of migrated user jean.doe does not point to a known group.
[Tue Jan 26 13:38:02.397928 2016] [:error] [pid 7427]
LDAPEntry(ipapython.dn.DN('uid=jean.doe,cn=users,cn=accounts,dc=example,dc=com'),
{u'mailQuotaSize': ['2048000'], u'cn': ['DOE'], u'uid': [u'jean.doe'],
u'objectClass': [u'ipaobject', u'organizationalperson', u'qmailuser',
u'top', u'ipasshuser', u'inetorgperson', u'person', u'krbticketpolicyaux',
u'krbprincipalaux', u'shadowaccount', u'qmailUser', u'inetuser',
u'posixaccount'], u'loginShell': ['/bin/bash'], u'uidNumber': ['1001'],
u'gidNumber': [u'1000'], u'ipauniqueid': ['autogenerate'],
u'krbprincipalname': [u'jean@example.com'], u'mailMessageStore':
['/var/vmail/jean.doe'], u'description': ['__no_upg__'], u'displayName':
['Jean Doe'], u'userPassword': ['{SSHA}NIxCImzQDagloyVdMtheC4wDMUImxW85'],
u'accountStatus': ['yes'], u'mailAlternateAddress': ['r...@example.com', '
postmas...@example.com'], u'sn': ['Jean'], u'homeDirectory':
['/var/vmail/jean.doe'], u'mail': ['jean@example.com'], u'givenName':
['DOE']})
[Tue Jan 26 13:38:02.398937 2016] [:error] [pid 7427] ipa: WARNING: GID
number 1000 of migrated user jeane.doe does not point to a known group.
[Tue Jan 26 13:38:02.399703 2016] [:error] [pid 7427]
LDAPEntry(ipapython.dn.DN('uid=jeane.doe,cn=users,cn=accounts,dc=example,dc=com'),
{u'mailQuotaSize': ['1024000'], u'cn': ['DOE'], u'uid': [u'jeane.doe'],
u'objectClass': [u'ipaobject', u'organizationalperson', u'qmailuser',
u'top', u'ipasshuser', u'inetorgperson', u'person', u'krbticketpolicyaux',
u'krbprincipalaux', u'shadowaccount', u'qmailUser', u'inetuser',
u'posixaccount'], u'loginShell': ['/bin/bash'], u'uidNumber': ['1002'],
u'gidNumber': [u'1000'], u'ipauniqueid': ['autogenerate'],
u'krbprincipalname': [u'jeane@example.com'], u'mailMessageStore':
['/var/vmail/jeane.doe'], u'description': ['__no_upg__'], u'displayName':
['Jeane Doe'], u'userPassword': ['{SSHA}+fXBt+2vlneTFUDhnEv9YvHS4Zo65LIT'],
u'accountStatus': ['yes'], u'sn': ['Jeane'], u'homeDirectory':
['/var/vmail/jeane.doe'], u'mail': ['jeane@example.com'], u'givenName':
['DOE']})

Regards.

2016-01-26 11:22 GMT+01:00 wodel youchi :

> Thanks I will try and report back.
>
> I am using Centos 7.2x64 with latest updates
>
> and ipa-server-4.2.0-15.el7.centos.3.x86_64
>
> Regards
>
> 2016-01-26 10:53 GMT+01:00 Martin Kosek :
>
>> On 01/26/2016 10:16 AM, wodel youchi wrote:
>> > Hi,
>> >
>> > I am a newbie in freeipa. I am trying to use it with our mail server.
>>
>> Cool! What is your version of the FreeIPA server? It will be important for
>> further investigation.
>>
>> > Our mail server uses openldap with one external schema : qmail.schema,
>> we
>> > use it especially for mailQuota, mailAlternateAddress,
>> > mailForwardingAddress and AccountStatus.
>> >
>> > I tried to import this schema to freeipa using ipa-ldap-updater.
>> > I am not sure if I succeeded, but when I tried : ipa config-mod
>> > --addattr=ipaGroupObjectClasses=qmailUser it worked and I can see the
>> > objectClass.
>> >
>> >
>> > [root@ipamaster work]# ipa config-show --all
>> >   dn: cn=ipaConfig,cn=etc,dc=example,dc=com
>> >   Longueur maximale du nom d'utilisateur: 32
>> >   Base du répertoire utilisateur: /home
>> >   Interprèteur par défaut: /bin/sh
>> >   Groupe utilisateur par défaut: ipausers
>> >   Domaine par défaut pour les courriels: example.com
>> >   Limite de temps d'une recherche: 2
>> >   Limite de taille d'une recherche: 100
>> >   Champs de recherche utilisateur:
>> uid,givenname,sn,telephonenumber,ou,title
>> >   Group search fields: cn,description
>> >   Activer le mode migration: TRUE
>> >   Base de sujet de certificat: O=EXAMPLE.COM
>> >   Classes d'objets de groupe par défaut: top, ipaobject, groupofnames,
>> > ipausergroup, nestedgroup
>> >   Classes d'objets utilisateur par défaut: ipaobject, person, top,
>> > ipasshuser, inetorgperson, organizationalperson,
>> >krbticketpolicyaux,
>> > krbprincipalaux, *qmailUser*, inetuser, posixaccount
>> >   Notification d'expiration de mot de passe (jours): 4
>> >   Fonctionnalités du greffon mots de passe: AllowNThash
>> >   Ordre de la mappe des utilisateurs SELinux:
>> >
>> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
>> >   Utilisateur SELinux par défaut: unconfined_u:s0-s0:c0.c1023
>> >   Types de PAC par défaut: nfs:NONE, MS-PAC
>> >   aci: (targetattr = "cn || createtimestamp || entryusn ||
>> > ipacertificatesubjectbase || ipaconfigstring || ipacustomfields ||
>> >ipadefaultemaildomain || ipadefaultloginshell ||
>> > ipadefaultprimarygroup || ipagroupobjectclasses ||
>> >ipagroupsearchfields || ipahomesrootdir || ipakrbauthzdata ||
>> > ipamaxusernamelength || ipamigrationenabled ||
>> >