Done and done, although imported users' membership in their OpenLDAP primary group wasn't preserved because a al catch22, that group could be made default until it was imported, but was easily rectified via the UI

I can almost live with these gigantic UIDs set for new users but the default GID, in spite of having set the default group (which is respected, but i would have expected the default GID to follow?) gets set to some unique and amusingly massive value. i've trawled a few old list posts but as with any project that spans years, you never know if you're reading something that became definitive or not, so i ask again:

Is it possible to pin new users' GID to my POSIX legacy "all-users" GID? And is it possible to elect a starting UID? Doesn't (although i'd prefer it) have to be a continuation of the POSIX range (1100+) i imported but something more humanly parseable would be better. In spite of an early post i came across which says "consider that future merger", it ain;'t going to happen on a F500 scale for us

Now for something completely different(ish): why was 4.x never build as EL6 RPMs? I am "mildly" resenting having to set up EL7, with all of it's uncharming peculiarities, in order to get relatively recent IPA 4.1 thus preserving future upgradability.

Thanks very much, Rob and Martin, for your quick and helpful replies


Cal Sawyer | Systems Engineer | BlueBolt Ltd

On 04/11/15 15:37, Rob Crittenden wrote:
Cal Sawyer wrote:
That's terrific, Rob - thanks very much.  Users and Groups import
smoothly with a little additional tweaking

ipa -v migrate-ds --with-compat
--group-objectclass="posixGroup" ldap://

boom, all users and groups imported ... but without group membership.
This is the RFC2307 schema. I think to fix you'd have to delete all IPA
users and groups and re-migrate.

The structure of Group in OpenLDAP is:

# power, Group, ldapdomain.local
dn: cn=systems,ou=Group,dc=ldapdomain,dc=local
cn: systems
gidNumber: 1112
objectClass: posixGroup
memberUid: usera
memberUid: userb

and IPA's schema appears, with one exception (objectClass: top), to match:

# admins, groups, compat, ipadomain.local
dn: cn=admins,cn=groups,cn=compat,dc=ipadomain,dc=local
objectClass: posixGroup
objectClass: top
gidNumber: 1944000000
memberUid: admin
cn: admins
That's the rfc 2307 compatibility view. If you look in
cn=admins,cn=groups,cn=accounts,dc=ipadomain,dc=local you'll see how it
is actually stored.

A side question:  can i use migrate-ds to bring in automount and sudoer
maps from OpenLDAP?
It's only users and groups right now.

You might have some luck with automount importing via LDIF but at least
the DN structure will need to be modified. You'd need to be pretty
careful that the IPA schema matches your current schema.

I think with sudo you'd be out of luck as IPA uses its own schema for
storing the sudo components and rules.

thanks again

Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575 |

On 04/11/15 13:56, Rob Crittenden wrote:
Cal Sawyer wrote:

Very new to IPA and setting up a proof of concept system that i hope
will replace my existing OpenLDAP 2.3 (no SASL) setup.  I'm trying to
import People, Group ou's into IPA using "ipa migrate-ds".  The IPA and
existing LDAP directories have different BaseDNs (eg ipadomain.local on
IPA, ldapdomain.local on LDAP 2.3) as i want to ideally construct a
completely new directory that we will then switch our clients over to.

ipa migrate-ds --schema=RFC2307
--user-container="dc=ldapdomain,dc=local" ldap://

whatever i try (w or w/o --schema=RFC2307) , the response is the same:

      ipa: ERROR: Insufficient access:  Invalid credentials

or with a verbose flag:

      ipa: INFO: Forwarding 'migrate_ds' to server
      ipa: ERROR: Insufficient access:  Invalid credentials

manager naturally exists in ldapdomain.local and i've definitely
supplied the correct password (we use the same creds to manage LDAP
using phpldapadmin)

Hoping that someone has some experience with this and can point me in
the right direction?
It is binding to openldap using cn=Directory Manager. If your admin user
that can read userPassword is named something different then pass it in
using the --binddn option.


Manage your subscription for the Freeipa-users mailing list:
Go to for more info on the project

Reply via email to