[Freeipa-users] FreeIPA and Samba4
Sumit Bose
sbose at redhat.com
Wed Nov 4 08:51:43 UTC 2015
On Tue, Nov 03, 2015 at 08:06:49PM +0100, Troels Hansen wrote:
> Hi, I got a bit further.
> I fount the error, being that I had some groups from the old LDAP with gid aroud 500, and current ID range i IPA sat to start at 2000, which was my start UID on the old LDAP.
The SIDs are generated based on the UID or GID and the data from a
matching idrange, see http://www.freeipa.org/page/V3/ID_Ranges for
details about the idranges.
To get SIDs assigned to the old entries you have to add a new idrange
for the local user:
ipa idrange-add ----type=ipa-local --base-id=500 --range-size=100 --rid-base=1000000 --secondary-rid-base=1000200
With this the UIDs and GIDs between 500 and 600 will get SIDs with RIDs
in the range from 1000000 to 1000100 (see kine above why there is a
secondard RID base).
>
> Is it possible to "reset" the base UID/GID that IPA assigns to the next user? I can't find it saved in the LDAP anywhere?
New IDs are assigned by the DNS plugin, please see
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Managing-Unique_UID_and_GID_Attributes.html
and
http://directory.fedoraproject.org/docs/389ds/design/dna-plugin.html for
details.
Please note that although they are somewhat related there currently is
no automatic configuration of the ranges used by the DNA plugin and the
ranges managed by the 'ipa idrange-*' utility. There is ticket
https://fedorahosted.org/freeipa/ticket/3609 to fix this.
HTH
bye,
Sumit
>
> ----- On Nov 3, 2015, at 1:36 PM, Sumit Bose sbose at redhat.com wrote:
>
> > On Tue, Nov 03, 2015 at 01:09:53PM +0100, Troels Hansen wrote:
> >> Hi again, so I finally got time to look further into this.
> >>
> >> This task works:
> >>
> >> dn: cn=$TIME-$FQDN-$LIBARCH,cn=ipa-sidgen-task,cn=tasks,cn=config
> >> add:objectclass:top,extensibleObject
> >> add:cn:$TIME-$FQDN-$LIBARCH
> >> add:nsslapd-basedn:"$SUFFIX"
> >> add:delay:0
> >> add:ttl:3600
> >>
> >> However, the task gets generated, but no output can be pulled from the task:
> >>
> >> ldapsearch -D "cn=Directory Manager" -W -b
> >> 'cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config'
> >> Enter LDAP Password:
> >> # extended LDIF
> >> #
> >> # LDAPv3
> >> # base
> >> <cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config>
> >> with scope subtree
> >> # filter: (objectclass=*)
> >> # requesting: ALL
> >> #
> >>
> >> # 1446551851-kenai.casalogic.lan-64, ipa-sidgen-task, tasks, config
> >> dn: cn=1446551851-kenai.casalogic.lan-64,cn=ipa-sidgen-task,cn=tasks,cn=config
> >> objectClass: top
> >> objectClass: extensibleObject
> >> nsslapd-basedn: dc=casalogic,dc=lan
> >> delay: 0
> >> cn: 1446551851-kenai.casalogic.lan-64
> >> ttl: 3600
> >> nstaskcurrentitem: 1
> >> nstasktotalitems: 1
> >> nstaskexitcode: 32
> >>
> >> # search result
> >> search: 2
> >> result: 0 Success
> >>
> >> # numResponses: 2
> >> # numEntries:
> >>
> >> Only a exitcode 32
> >> The nstaskcurrentitem and nstasktotalitems remains the same till the task
> >> disappeares.
> >> Any way do debug these taske further to find out which user it stops at, as it
> >> looks like it detects an error at one user and stops the task?
> >
> > You can activate 'Plug-in debugging' by setting the
> > nsslapd-errorlog-level attribute of cn=config to 65536, see
> > http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting for
> > details. Make sure to switch it back to 0 after running the sidgen task
> > because the logging is quite expensive.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> >>
> >> ----- On Oct 30, 2015, at 3:19 PM, Alexander Bokovoy abokovoy at redhat.com wrote:
> >>
> >> > On Fri, 30 Oct 2015, Troels Hansen wrote:
> >> >>
> >> >>
> >> >>
> >> >>> I think it should be
> >> >>> add:nsslapd-basedn: cn=accounts,$SUFFIX
> >> >>> not
> >> >>> add:basedn:"cn=accounts,$SUFFIX"
> >> >>>
> >> >>> this is what sidgen task expects and it returns constraint violation
> >> >>> error if parameters are wrong:
> >> >>>
> >> >>> str = fetch_attr(e, "nsslapd-basedn", NULL);
> >> >>> if (str == NULL) {
> >> >>> LOG_FATAL("Missing nsslapd-basedn!\n");
> >> >>> *returncode = LDAP_CONSTRAINT_VIOLATION;
> >> >>> ret = SLAPI_DSE_CALLBACK_ERROR;
> >> >>> goto done;
> >> >>> }
> >> >>>
> >> >>
> >> >>I think you are right.
> >> >>Don't know what I have tested, but it brings me a different error, that I didn't
> >> >>see before:
> >> >>
> >> >>ipa.ipapython.ipaldap.IPAdmin: DEBUG: Unhandled LDAPError: OPERATIONS_ERROR:
> >> >>{'desc': 'Operations error'}
> >> >>ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR: Add failure Operations
> >> >>error:
> >> >>ipa.ipaserver.install.ipa_ldap_updater.LDAPUpdater_NonUpgrade: INFO: The
> >> >>ipa-ldap-updater command was successful
> >> >>
> >> >>Where did you find the source for the sidgen task? I could try looking at at it
> >> >>myself, but can't find it.
> >> > You can check it here:
> >> > https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/ipa-sidgen/ipa_sidgen_task.c#n221
> >> >
> >> > --
> >> > / Alexander Bokovoy
> >>
> >> --
> >> Med venlig hilsen
> >>
> >> Troels Hansen
> >>
> >> Systemkonsulent
> >>
> >> Casalogic A/S
> >>
> >>
> >> T (+45) 70 20 10 63
> >>
> >> M (+45) 22 43 71 57
> >>
> >> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og
> >> meget mere.
> >>
> >> --
> >> 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
>
> --
> Med venlig hilsen
>
> Troels Hansen
>
> Systemkonsulent
>
> Casalogic A/S
>
>
> T (+45) 70 20 10 63
>
> M (+45) 22 43 71 57
>
> Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere.
>
> --
> 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
More information about the Freeipa-users
mailing list