Joseph Fry via FreeIPA-users wrote: > Well, I managed to figure out the %deref_r directive is what I was looking for and got my update file working. I am posting it here for anyone who wants to do the same. Its actually pretty simple... just creates two containers in compat, one contains pseudo entries for every host, and the other contains psudo entries for every hostgroup with the member attribute (pointing to the corresponding pseudo host entries). I'm sure it can be improved, but it looks like it meets my needs in early testing. > > Just save to a file and run "ipa-ldap-updater <filename>" and your dumb AD-only tool can ingest the devices (or at least mine can, you may need to bring over some other attributes). Glad to see you got it working and thanks for contributing your solution. rob > > > # Delete the adcomputers and adcomputergroups containers. Not really necessary but > # its useful to start with a clean slate during testing, as updating things can lead > # some strangeness > > dn: cn=adcomputers, cn=Schema Compatibility, cn=plugins, cn=config > deleteentry: > > dn: cn=adcomputergroups, cn=Schema Compatibility, cn=plugins, cn=config > deleteentry: > > # Create the adcomputers container and map the objects and attributes from the ipaHosts > # Note: This will bring every host in, though it could be filtered with the search-filter > # below if desired. > > dn: cn=adcomputers, cn=Schema Compatibility, cn=plugins, cn=config > default:objectClass: top > default:objectClass: extensibleObject > default:cn: adcomputers > default:schema-compat-container-group: cn=compat, $SUFFIX > default:schema-compat-container-rdn: cn=adcomputers > default:schema-compat-search-base: cn=computers, cn=accounts, $SUFFIX > default:schema-compat-search-filter: (&(fqdn=*)(objectClass=ipaHost)) > default:schema-compat-entry-rdn: cn=%first("%{fqdn}") > default:schema-compat-check-access: yes > default:schema-compat-entry-attribute: objectclass=computer > default:schema-compat-entry-attribute: cn=%{fqdn} > default:schema-compat-entry-attribute: sAMAccountType=805306369 > default:schema-compat-entry-attribute: dNSHostName=%{fqdn} > default:schema-compat-entry-attribute: operatingSystem=%{nsOsVersion} > default:schema-compat-entry-attribute: name=%{serverHostName} > default:schema-compat-entry-attribute: sAMAccountName=$$%{serverHostName} > default:schema-compat-entry-attribute: location=%{nsHostLocation} > > # Create the adcomputergroups container and map the relevant attributes from the ipahostgroups > > dn: cn=adcomputergroups, cn=Schema Compatibility, cn=plugins, cn=config > default:objectClass: top > default:objectClass: extensibleObject > default:cn: adcomputergroups > default:schema-compat-container-group: cn=compat, $SUFFIX > default:schema-compat-container-rdn: cn=adcomputergroups > default:schema-compat-search-base: cn=hostgroups, cn=accounts, $SUFFIX > default:schema-compat-search-filter: (&(member=*)(objectClass=ipahostgroup)) > default:schema-compat-entry-rdn: cn=%{cn} > default:schema-compat-entry-check-access: yes > default:schema-compat-entry-attribute: objectclass=group > default:schema-compat-entry-attribute: objectclass=groupOfNames > default:schema-compat-entry-attribute: cn=%{cn} > default:schema-compat-entry-attribute: distinguishedName=cn=%{cn},cn=adcomputergroups,cn=compat,$SUFFIX > #default:schema-compat-entry-attribute: groupType=-2147483650 > #default:schema-compat-entry-attribute: sAMAccountType=268435456 > default:schema-compat-entry-attribute: name=%{cn} > default:schema-compat-entry-attribute: member=cn=%deref_r("member","fqdn"),cn=adcomputers,cn=compat,$SUFFIX > #default:schema-compat-entry-attribute: sAMAccountName=%{cn} > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > _______________________________________________ FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

Thanks for that, would have been useful. However it still doesn't lay out all of the functions. I had to figure out that %deref_r allowed me to do a %deref but append a string to every result, through trial and error. I never did figure out what the %deref_f , %deref_rf, %link and %collect functions did, and I haven't seen them documented anywhere.

Perfect, thanks! Just curious... Can you explain why %deref_r works in this line, but just a plain %deref does't? default:schema-compat-entry-attribute: member=cn=%deref_r("member","fqdn"),cn=adcomputers,cn=compat,$SUFFIX Essentially I am just taking the fqdn of the ipahost member attribute and inserting inline to form: cn=<fqdn>,cn=adcomputers,cn=compat,dc=lab,dc=local Doing member=%deref("member","fqdn") by itself returned all of the values I needed, but when I tried to use it within a string I got no member attribute at all. I see nothing in the documentation that explains the difference in the output, only a difference in how the return values are determined. Apparently I just got lucky that %deref_r did what I wanted, as I don't suspect that it was intended to work that differently than %deref (based on the documentation).

On ti, 20 heinä 2021, Joseph Fry via FreeIPA-users wrote: Regardless what compatibility plugin represents, the resulting entries are processed by 389-ds LDAP server core. They have to follow the logic and rules defined in 389-ds. As Rob said, defining an object class for 'computer' is the only option. There is another one, of course, to relax schema checks in the whole 389-ds, but it would mean eventually breaking the consistency of this deployment as other schema violations would not be detected. Filing a feature request to 389-ds will not help. They have spent several years going into the opposite direction and enforcing the schema everywhere.

Joseph Fry via FreeIPA-users wrote: I didn't search particularly hard for what the AD Computers objectclass is supposed to look like but I think I found the OID anyway. Something like this is a bare-bones representation that *might* work. It's basically untested other than it didn't burn down my IPA install: dn: cn=schema add: objectClasses: (1.2.840.113556.1.3.30 NAME 'Computers' DESC 'AD Computers' SUP top MAY (cn))

> Thanks Rob... one problem, the objectclass name is > 'computer', and I missed it. > > What is the proper update syntax to remove the objectclass from the schema. > > I tried the following but it didn't work: > dn: cn=schema > remove: objectClasses: (1.2.840.113556.1.3.30 NAME 'Computers' DESC 'AD > Computers' SUP top MAY (cn)) > > I suspect I am overcomplicating it. Bump