Samba4 loading schema.ldif

[Gémes Géza]

Hi Mat,
> On 04/12/2012 07:50 AM, Gémes Géza wrote:
>> 2012-04-12 02:36 keltezéssel, Matthieu Patou írta:
>>> On 04/11/2012 01:28 PM, Gémes Géza wrote:
>>>> Hi,
>>>>
>>>> After successful generation of ldif file from the OpenLDAP schema
>>>> using
>>>> the patch developed by Matthieu for oLschema2ldif I'm stuck now with
>>>> loading it to Samba4.
>>>> If I ad it by local ldbedit (cat schema.ldif | ldbedit -H
>>>> /usr/local/samba/private/....) it gets added, but Active Directory
>>>> Schema MMC gets the impression, that the Samba4 domain controller (the
>>>> only in this domain/forest so far) is not available. I reverted
>>>> back to
>>>> backups.
>>> As I said any attribute that has a DN syntax will just destroy your
>>> schema, you need to fix the oLschema2ldif so that it generate the
>>> oMObjectClass or your schema will be waxed.
>> In the meantime I've did my homework and found:
>> http://lists.samba.org/archive/samba-technical/2011-May/077537.html
>> Does that mean, that we don't know the exact meaning of oMObjectClass
>> attribute and need to ad it based on the object syntax attribute?
> It means that I suspect that windows AD automatically adds it when
> it's needed and we don't do it and doing so break our schema because
> we expect this on some attributes that's why we made the schema not
> modifiable by default.
I've made a small progress (baby-steps) in fixing oLschema2ldif behavior
(trying to add oMObjectClass where needed, when oMSyntax == 127), by adding
if ( strcmp(oMSyntax, "127") == 0 ){
    MSG_ADD_STRING("oMObjectClass", (map->oMObjectClass).data);
}
around line number 485 (patched version with your patch applied), but I
get the correct oMObjectClass base64 encoding truncated at 2/3 in the
ldif (e.g I get KwwCh3Mc instead of KwwCh3McAIVK).
I'm out of any idea of what could be the origin of this truncation.
>
>> looking at my schema partition with ldbsearch -H
>> /usr/local/samba/private/sam.ldb.d/CN\=SCHEMA\,CN\=CONFIGURATION\,DC\=KZSDABAS\,DC\=HU.ldb
>>
>> | grep ^oMObjectClass | sort | uniq I've found, that the possible values
>> are:
>> oMObjectClass:: KoZIhvcUAQEBBg==
>> oMObjectClass:: KoZIhvcUAQEBCw==
>> oMObjectClass:: KoZIhvcUAQEBDA==
>> oMObjectClass:: KwwCh3McAIVc
>> oMObjectClass:: KwwCh3McAIVK
>> Unfortunately a base64 decoding of them (I've used the base64 module of
>> python) gives just binary data, so it is still not clear to me what do
>> they represent.
> You could specify them in binary form it didn't hurt.
>
>>>> If I allow schema updates (dsdb: schema update allowed = yes in
>>>> smb.conf) then it still seems to be not enabled from a Win7 client
>>>> (loged in as a member of Schema Admins group):
>>>>> ldifde -i -f c:\dhcp.ldf -v
>>>> Connecting to "samba4.kzsdabas.hu"
>>>> Logging in as current user using SSPI
>>>> Importing directory from file "c:\dhcp.ldf"
>>>> Lazy commit support not available on the server, lazy commit will be
>>>> disabled.
>>>> Loading entries
>>>> 1: CN=dhcpPrimaryDN,CN=Schema,CN=Configuration,DC=kzsdabas,DC=hu
>>>>
>>>> Add error on entry starting on line 1: Unwilling To Perform
>>>> The server side error is: 0x2035 The server is unwilling to process
>>>> the
>>>> request.
>>>>
>>>> The extended server error is:
>>>> 00002035: schema_data_add: updates are not allowed: reject request
>>> Did you restart samba after changing the smb.conf ?
> Did you investigate a bit more this issue ?would be great to see the
> problem maybe doing a tcpdump/wireshark trace will tell us more.
>
> Matthieu.
>
No unfortunately I didn't. Instead tried to fix oLschema2ldif as I wrote
before.

Thank you!

Cheers

Geza