It just depends on what you need the ldap side for, for example our
environment we use it for authentication with linux systems. So we use the
posixaccount type. That type has some required attributes, so I have to
ensure all entries have:
cn, description, uid, gecos, uidnumber, gidnumber, homedirectory,
loginshell.
You need to decide what requirements you need on your ldap side, and then
use a schema that works for you. Schemas will have certain required
attributes.
The object class settings will likely be the same for all users.
Here is an example from my config:
<dataset>
<name>objectClass</name>
<forceValues>
<string>"account"</string>
<string>"posixAccount"</string>
<string>"shadowAccount"</string>
<string>"ldapPublicKey"</string>
<string>"top"</string>
</forceValues>
</dataset>
Our users are added with the above object class attributes.
You error indicated that it needed an objectclass, so to start you could
pick something easy like user, or account, and just make sure you have that
objectclass defined, and whatever attributes it requires.
Hope that helps!
-Joel
On Mon, Oct 22, 2012 at 7:42 PM, Mike Svoboda <[email protected]> wrote:
> Hey Joel
>
> I don’t mean to sound like an idiot here, but I've really been
> struggling with this and Google searching like mad to try to figure out how
> to extract the necessary bits needed from Active Directory. There really
> isn't any clear documentation on how to extract the needed schema bits from
> Active Directory and get them imported into OpenLDAP's schema.
>
>
> Here's what I've gotten so far:
>
> $ ldapsearch -H <active directory server> -b
> "CN=Aggregate,CN=Schema,CN=Configuration,DC=linkedin,DC=biz" -D "bind user"
> -w "bind password" -s base objectclass=subschema attributetypes
>
>
>
>
>
>
> This dumps what looks like the LDIF of the Active Directory subschema
> attributetypes. I believe this is the ldif I need to import into OpenLDAP.
> Please let me know if I'm off base here.
>
> # extended LDIF
> #
> # LDAPv3
> # base <CN=Aggregate,CN=Schema,CN=Configuration,DC=linkedin,DC=biz> with
> scope baseObject
> # filter: objectclass=subschema
> # requesting: attributetypes
> #
>
> attributeTypes: ( 1.2.840.113556.1.4.7000.102.50621 NAME
> 'msExchMessageHygiene
> BlockedDomain' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
> attributeTypes: ( 1.2.840.113556.1.4.609 NAME 'sIDHistory' SYNTAX
> '1.3.6.1.4.1
> .1466.115.121.1.40' )
> attributeTypes: ( 1.2.840.113556.1.4.145 NAME 'revision' SYNTAX
> '1.3.6.1.4.1.1
> 466.115.121.1.27' SINGLE-VALUE )
> attributeTypes: ( 1.2.840.113556.1.4.1983 NAME 'msTSMaxIdleTime' SYNTAX
> '1.3.6
> .1.4.1.1466.115.121.1.27' SINGLE-VALUE )
> …
> …..
> …
>
>
> I've then seen tutorials that you need to convert this from slapd.conf
> format into cn=config, so, I've created a temporary directory to try to do
> this:
>
>
> # cat /var/tmp/mike.conf
> include /var/tmp/mike/core.schema
> include /var/tmp/mike/cosine.schema
> include /var/tmp/mike/inetorgperson.schema
> include /var/tmp/mike/active_directory.schema
>
> This complains on the active_directory.schema that I extracted out from
> the above command when I attempt to convert into cn=config format.
>
> # slaptest -f /var/tmp/mike.conf -F /var/tmp/ldaptemp
> /var/tmp/mike/active_directory.schema: line 10 attributeTypes:: Invalid
> NAME: "msExchMessageHygiene BlockedDomain"
> slaptest: bad configuration directory!
>
>
>
> This is a total n00b question, but would someone mind helping point me
> in the right direction on what I need to execute / accomplish in order to
> extend the OpenLDAP schema so I can use LSC to sync users from Active
> Directory into it? Executing ldapsearch against a user entry, these are
> all the attributes that exist for a user. I assume since I only need to
> have lsc sync a portion of them, I do not need to extend OpenLDAP's schema
> to support all of these attributes? Right?
>
>
> accountExpires:
> adminCount:
> badPasswordTime:
> badPwdCount:
> businessCategory:
> cn:
> codePage:
> company:
> countryCode:
> department:
> departmentNumber:
> directReports:
> displayName:
> distinguishedName:
> dn:
> dSCorePropagationData:
> employeeNumber:
> employeeType:
> extensionAttribute3:
> extensionAttribute4:
> extensionAttribute5:
> gecos:
> gidNumber:
> givenName:
> homeMDB:
> homeMTA:
> homePhone:
> instanceType:
> lastLogon:
> lastLogonTimestamp:
> legacyExchangeDN:
> lockoutTime:
> loginShell:
> logonCount:
> mail:
> mailNickname:
> managedObjects:
> manager:
> mDBUseDefaults:
> memberOf:
> mobile:
> msExchALObjectVersion:
> msExchCoManagedObjectsBL:
> msExchELCMailboxFlags:
> msExchHomeServerName:
> msExchMailboxGuid::
> msExchMailboxSecurityDescriptor::
> msExchMobileAllowedDeviceIDs:
> msExchMobileMailboxFlags:
> msExchMobileMailboxPolicyLink:
> msExchObjectsDeletedThisPeriod:
> msExchPoliciesExcluded:
> msExchRBACPolicyLink:
> msExchRecipientDisplayType:
> msExchRecipientTypeDetails:
> msExchTextMessagingState:
> msExchUMDtmfMap:
> msExchUserAccountControl:
> msExchUserCulture:
> msExchVersion:
> msExchWhenMailboxCreated:
> name:
> objectCategory:
> objectClass:
> objectGUID::
> objectSid::
> physicalDeliveryOfficeName:
> primaryGroupID:
> proxyAddresses:
> pwdLastSet:
> result:
> sAMAccountName:
> sAMAccountType:
> search:
> showInAddressBook:
> sn:
> streetAddress:
> telephoneNumber:
> textEncodedORAddress:
> title:
> uidNumber:
> unixHomeDirectory:
> userAccountControl:
> userPrincipalName:
> uSNChanged:
> uSNCreated:
> whenChanged:
> whenCreated:
>
> Thanks
> Mike
>
>
>
> From: Joel Foote <[email protected]>
> Date: Sunday, October 21, 2012 10:15 AM
> To: Mike Svoboda <[email protected]>
> Cc: Jonathan Clarke <[email protected]>, "
> [email protected]" <[email protected]>
>
> Subject: Re: [lsc-users] Sync AD --> OpenLDAP help needed
>
> Hi Mike,
>
> You will need to add the appropriate object classes for your LDAP schema.
> PosxAccount is a common one, but it is all going to depend on what you need
> on the side that is using LDAP as a directory. Figure out what the correct
> LDAP entry should look like when it is synced, and use those attributes.
>
> -Joel
>
> On Sun, Oct 21, 2012 at 10:33 AM, Mike Svoboda <[email protected]>wrote:
>
>> Open source friends! Thanks for the tip! I think I'm getting closer
>> to having a sync execute.
>>
>> So, I executed this on the destination LDAP server to create the base
>> directory structure:
>>
>> # cat /var/tmp/add-to-ldap
>> dn: dc=linkedin,dc=biz
>> objectClass: top
>> objectClass: domain
>>
>> dn: ou=staff users,dc=linkedin,dc=biz
>> objectClass: top
>> objectClass: organizationalUnit
>> ou: Staff Users
>>
>>
>> Executed ldapadd:
>>
>> # ldapadd -D "cn=manager,dc=linkedin,dc=biz" -w xxxx -f
>> /var/tmp/add-to-ldap
>> adding new entry "dc=linkedin,dc=biz"
>> adding new entry "ou=staff users,dc=linkedin,dc=biz"
>>
>>
>>
>>
>> It appears to have worked. I see the base directory entries now.
>>
>>
>>
>> # ldapsearch -b "dc=linkedin,dc=biz" -D "cn=manager,dc=linkedin,dc=biz"
>> -w xxxx '(objectclass=*)' -s sub
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <dc=linkedin,dc=biz> with scope subtree
>> # filter: (objectclass=*)
>> # requesting: ALL
>> #
>>
>> # linkedin.biz
>> dn: dc=linkedin,dc=biz
>> objectClass: top
>> objectClass: domain
>> dc: linkedin
>>
>> # staff users, linkedin.biz
>> dn: ou=staff users,dc=linkedin,dc=biz
>> objectClass: top
>> objectClass: organizationalUnit
>> ou: Staff Users
>>
>> # search result
>> search: 2
>> result: 0 Success
>>
>>
>>
>> Here's the relevant parts of my lsc.xml now, just trying to get
>> something to work.
>>
>>
>> <tasks>
>> <task>
>> <name>Sync_Active_Directory_Users</name>
>> <bean>org.lsc.beans.SimpleBean</bean>
>>
>> <ldapSourceService>
>> <name>ad-src-service</name>
>> <connection reference="Active_Directory" />
>> <baseDn>ou=staff users,dc=linkedin,dc=biz</baseDn>
>> <pivotAttributes><string>cn</string></pivotAttributes>
>> <fetchedAttributes>
>> <string>cn</string>
>> </fetchedAttributes>
>> <getAllFilter>(objectClass=user)</getAllFilter>
>> <getOneFilter>(&(objectClass=user)(cn={cn}))</getOneFilter>
>> </ldapSourceService>
>>
>> <ldapDestinationService>
>> <name>openldap-dst-service</name>
>> <connection reference="OpenLDAP" />
>> <baseDn>ou=staff users,dc=linkedin,dc=biz</baseDn>
>> <pivotAttributes><string>cn</string></pivotAttributes>
>> <fetchedAttributes>
>> <string>cn</string>
>> </fetchedAttributes>
>> <getAllFilter>(objectClass=user)</getAllFilter>
>> <getOneFilter>(&(objectclass=user)(cn={cn}))</getOneFilter>
>> </ldapDestinationService>
>>
>> <propertiesBasedSyncOptions>
>> <mainIdentifier>"cn=" + srcBean.getDatasetFirstValueById("cn")
>> + ",ou=Staff Users,dc=linkedin,dc=biz"</mainIdentifier>
>> <defaultDelimiter>;</defaultDelimiter>
>> <defaultPolicy>FORCE</defaultPolicy>
>> <dataset>
>> <name>objectclass</name>
>> <policy>FORCE</policy>
>> <forceValues>
>> <string>"cn"</string>
>> </forceValues>
>> </dataset>
>> </propertiesBasedSyncOptions>
>>
>> </task>
>> </tasks>
>>
>>
>>
>> Here's execution.
>>
>> # lsc –s all
>>
>> …
>> …
>> Oct 21 17:26:50 - WARN - No clean filter has been specified for
>> task=Sync_Active_Directory_Users. During the clean phase, LSC wouldn't be
>> able to get the right entries and may delete all destination entries !
>> Oct 21 17:26:50 - INFO - Starting sync for Sync_Active_Directory_Users
>> Oct 21 17:26:51 - ERROR - Error while adding entry cn=Kian Chung,ou=Staff
>> Users,dc=linkedin,dc=biz in directory
>> :javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - no
>> objectClass attribute]; remaining name 'cn=Kian Chung,ou=Staff Users'
>> …
>> ..
>>
>> This repeats for the 4000+ entries.
>>
>> On the OpenLDAP server:
>>
>> Oct 21 17:26:50 slapd[22055]: conn=3511 op=0 BIND
>> dn="cn=manager,dc=linkedin,dc=biz" method=128
>> Oct 21 17:26:50 slapd[22055]: conn=3511 op=0 BIND
>> dn="cn=manager,dc=linkedin,dc=biz" mech=SIMPLE ssf=0
>> Oct 21 17:26:50 slapd[22055]: conn=3511 op=0 RESULT tag=97 err=0 text=
>> Oct 21 17:26:51 slapd[22055]: conn=3511 op=1 SRCH base="ou=staff
>> users,dc=linkedin,dc=biz" scope=2 deref=0
>> filter="(&(?objectClass=user)(cn=kian chung))"
>> Oct 21 17:26:51 slapd[22055]: conn=3511 op=1 SRCH attr=cn sn
>> Oct 21 17:26:51 slapd[22055]: conn=3511 op=9 ADD dn="cn=Kian
>> Chung,ou=Staff Users,dc=linkedin,dc=biz"
>> Oct 21 17:26:51 slapd[22055]: is_entry_objectclass("cn=Kian
>> Chung,ou=Staff Users,dc=linkedin,dc=biz", "2.5.17.0") no objectClass
>> attribute
>> Oct 21 17:26:51 slapd[22055]: No objectClass for entry (cn=Kian
>> Chung,ou=Staff Users,dc=linkedin,dc=biz)
>> Oct 21 17:26:51 slapd[22055]: conn=3511 op=7 RESULT tag=105 err=65
>> text=no objectClass attribute
>>
>>
>>
>> Did I miss creating something in the base directory structure from the
>> execution of ldapadd? Thanks again for the assistance!
>>
>> Mike
>>
>>
>>
>>
>> From: Jonathan Clarke <[email protected]>
>> Date: Saturday, October 20, 2012 5:16 AM
>> To: Mike Svoboda <[email protected]>
>> Cc: Joel Foote <[email protected]>, "[email protected]" <
>> [email protected]>
>>
>> Subject: Re: [lsc-users] Sync AD --> OpenLDAP help needed
>>
>> Hi Mike,
>>
>> On 20/10/12 03:06, Mike Svoboda wrote:
>>
>> No dice. I now am trying this:
>>
>> 33 <tasks>
>> 34 <task>
>> 35 <name>Sync_Active_Directory_Users</name>
>> 36 <bean>org.lsc.beans.SimpleBean</bean>
>> 37
>> 38 <ldapSourceService>
>> 39 <name>ad-src-service</name>
>> 40 <connection reference="Active_Directory" />
>> 41 <baseDn>ou=staff users,dc=linkedin,dc=biz</baseDn>
>> 42 <pivotAttributes><string>cn</string></pivotAttributes>
>> 43 <fetchedAttributes>
>> 44 <string>cn</string>
>> 45 <string>description</string>
>> 46 <string>name</string>
>> 47 <string>objectClass</string>
>> 48 <string>sn</string>
>> 49 <string>givenName</string>
>> 50 </fetchedAttributes>
>> 51 <getAllFilter>(objectClass=user)</getAllFilter>
>> 52 <getOneFilter>(&(objectClass=user)(cn={cn}))</getOneFilter>
>> 53 </ldapSourceService>
>> 54
>> 55 <ldapDestinationService>
>> 56 <name>openldap-dst-service</name>
>> 57 <connection reference="OpenLDAP" />
>> 58 <baseDn>ou=staff users,dc=linkedin,dc=biz</baseDn>
>> 59 <pivotAttributes><string>uid</string></pivotAttributes>
>> 60 <fetchedAttributes>
>> 61 <string>description</string>
>> 62 <string>cn</string>
>> 63 <string>sn</string>
>> 64 <string>givenName</string>
>> 65 <string>objectClass</string>
>> 66 <string>uid</string>
>> 67 <string>mail</string>
>> 68 </fetchedAttributes>
>> 69 <getAllFilter>(objectClass=*)</getAllFilter>
>> 70
>> <getOneFilter>(&(objectClass=*)(cn={cn}))</getOneFilter>
>> 71 </ldapDestinationService>
>> 72
>> 73 <propertiesBasedSyncOptions>
>> 74 <mainIdentifier>"cn=" +
>> srcBean.getDatasetFirstValueById("cn") + ",ou=Staff
>> Users,dc=linkedin,dc=biz"</mainIdentifier>
>> 75 <defaultDelimiter>;</defaultDelimiter>
>> 76 <defaultPolicy>FORCE</defaultPolicy>
>> 77 <dataset>
>> 78 <name>objectclass</name>
>> 79 <policy>FORCE</policy>
>> 80 <forceValues>
>> 81 <string>"cn"</string>
>> 82 </forceValues>
>> 83 </dataset>
>> 84 </propertiesBasedSyncOptions>
>> 85
>> 86 </task>
>> 87 </tasks>
>>
>>
>> Output of executing LSC:
>>
>>
>> Oct 20 01:04:25 - ERROR - Error while looking for
>> (&(objectClass=*)(cn=Jay Ramamurthi)) in ou=staff users,dc=linkedin,dc=biz:
>> javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object];
>> remaining name 'ou=staff users'
>> Oct 20 01:04:25 - ERROR - Error while looking for
>> (&(objectClass=*)(cn=Christopher Abrams)) in ou=staff
>> users,dc=linkedin,dc=biz: javax.naming.NameNotFoundException: [LDAP: error
>> code 32 - No Such Object]; remaining name 'ou=staff users'
>> Oct 20 01:04:25 - ERROR - Error while synchronizing ID {cn=Jay
>> Ramamurthi}: org.lsc.exception.LscServiceException:
>> javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object];
>> remaining name 'ou=staff users'
>> Oct 20 01:04:25 - ERROR - Error while synchronizing ID {cn=Christopher
>> Abrams}: org.lsc.exception.LscServiceException:
>> javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object];
>> remaining name 'ou=staff users'
>> Oct 20 01:04:25 - ERROR - All entries: 3999, to modify entries: 0,
>> successfully modified entries: 0, errors: 3999
>>
>> Output from syslog on the OpenLDAP server.
>>
>> Oct 20 01:04:25 slapd[22055]: conn=1067 op=3997 SRCH base="ou=staff
>> users,dc=linkedin,dc=biz" scope=2 deref=0
>> filter="(&(objectClass=*)(cn=justin church))"
>> Oct 20 01:04:25 slapd[22055]: conn=1067 op=3997 SRCH attr=description cn
>> sn givenName objectClass uid mail
>> Oct 20 01:04:25 slapd[22055]: conn=1067 op=3997 SEARCH RESULT tag=101
>> err=32 nentries=0 text=
>> Oct 20 01:04:25 slapd[22055]: conn=1067 op=3998 SRCH base="ou=staff
>> users,dc=linkedin,dc=biz" scope=2 deref=0 filter="(&(objectClass=*)(cn=jay
>> ramamurthi))"
>> Oct 20 01:04:25 slapd[22055]: conn=1067 op=3998 SRCH attr=description cn
>> sn givenName objectClass uid mail
>> Oct 20 01:04:25 slapd[22055]: conn=1067 op=3998 SEARCH RESULT tag=101
>> err=32 nentries=0 text=
>> Oct 20 01:04:25 slapd[22055]: conn=1067 op=3999 SRCH base="ou=staff
>> users,dc=linkedin,dc=biz" scope=2 deref=0
>> filter="(&(objectClass=*)(cn=christopher abrams))"
>> Oct 20 01:04:25 slapd[22055]: conn=1067 op=3999 SRCH attr=description cn
>> sn givenName objectClass uid mail
>> Oct 20 01:04:25 slapd[22055]: conn=1067 op=3999 SEARCH RESULT tag=101
>> err=32 nentries=0 text=
>>
>>
>>
>>
>> I'm guessing I have something wrong in my propertiesBasedSyncOptions
>> stanza.
>>
>>
>> These error messages indicate the issue is in the destination directory
>> allright (filter is "(&(objectClass=*)(cn=<fullname>))" as indicated in the
>> ldapDestinationService section of your config.
>>
>> The error logged by OpenLDAP, error 32 "No such entry" indicates that the
>> *base* of the search does not exist, that is the "ou=staff
>> users,dc=linkedin,dc=biz" entry. If it did exist, and no entries matched
>> the filter, the LDAP error code would be 0 (Success) but the number of
>> results would be 0. LSC will not (by design) create any entries other than
>> the ones you tell it to sync, that is it will not create the OU to hold
>> users if you told it to sync users. Creating it manually should make this
>> sync work.
>>
>> By the way, your filter could be optimized slightly
>> ("(&(objectClass=*)(cn={cn}))") since "(objectClass=*)" basically means
>> "everything" in LDAP, so this could be shortened to "(cn={cn})". On a
>> similar note (optimization), I would recommend against using full names for
>> syncs, but a unique ID instead (ie username, or employee number if you have
>> one) to avoid issues in the future with name changes (married name vs
>> maiden name) or two people with duplicate names. This is just optimization
>> though, so shouldn't stop you from getting your LSC sync working.
>>
>> Hope this helps,
>> Jonathan
>>
>> PS: it's good to see I'm not the only one doing LSC and CFEngine!! :)
>>
>
>
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users
