samba4: machine and user accounts - Samba

This is a discussion on samba4: machine and user accounts - Samba ; On Thu, May 22, 2008 at 02:17:53PM +1000, Andrew Bartlett wrote: > On Wed, 2008-05-21 at 23:53 -0400, Mike Wilkinson wrote: > > ldb: Unable to find backend for 'ldap://xxxx' > > I'm assuming it's local setup, I've searched for ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 32 of 32

Thread: samba4: machine and user accounts

  1. Re: samba4: machine and user accounts

    On Thu, May 22, 2008 at 02:17:53PM +1000, Andrew Bartlett wrote:
    > On Wed, 2008-05-21 at 23:53 -0400, Mike Wilkinson wrote:
    > > ldb: Unable to find backend for 'ldap://xxxx'
    > > I'm assuming it's local setup, I've searched for info on smbscript but
    > > found nothing more than a few irc logs that appear to have gone more
    > > smoothly. smbscript isn't installed in the target directory, I've added
    > > .../source/bin to the path. Any clues on what environment I need to set
    > > to have it find an ldap backend.


    > This *should* (I am assured) be fixed in current GIT. Do a new build,
    > and 'make install'. If that doesn't work, then clean out your build
    > tree and do a new build and 'make install'...

    Sorry, I thought I had this fixed but apparently $(basename) in make
    and basename the command-line utility do completely different things
    to a path. I must've been looking at the wrong symlinks when I was verifying
    my fix worked.

    It should really be fixed in git atm (revision 84d937).

    Cheers,

    Jelmer

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iQCVAwUBSDYmzwy0JeEGD2blAQIlKAQAnsA3gajYRjgue9KIyC l50yf4v8ticyTl
    Ppp4PKxgKdlVyRTO96TnV4FwMLRWddRHjxegsn0RodpPh1KmFz Dp9WP/eltE4VDD
    bHZ1mEBukkrDZAKnoqYJ7sDtHT9kinQ8FIm6qKQJu2cLTQR/otV+ZGkiW5qoMhPt
    zik6Jgiaou0=
    =HJbg
    -----END PGP SIGNATURE-----


  2. Re: samba4: machine and user accounts

    On Fri, May 23, 2008 at 12:01:50PM +1000, Andrew Bartlett wrote:
    > On Thu, 2008-05-22 at 14:06 -0400, Mike Wilkinson wrote:
    > > Tried the python version (the one that gets installed in
    > > /usr/local/samba), set PYTHONPATH to
    > > /usr/local/samba/lib/python2.4/site-packages and that throws


    > > Traceback (most recent call last):
    > > File "samba/bin/minschema.py", line 9, in ?
    > > sys.path.insert(0, "bin/python")
    > > NameError: name 'sys' is not defined


    > > I know nothing of python, is this some kind of python version dependancy?


    > No, I think that this is a 'minschema isn't tested, so it broke'
    > dependency... I hope Jelmer can comment further.


    This particular bug has been fixed and would indeed be a case of
    broken because untested.

    However, the conversion of minschema from EJS to Python isn't finished IIRC.
    You may want to use the EJS version of minschema for now.

    Cheers,

    Jelmer
    --

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iQCVAwUBSDYnrgy0JeEGD2blAQJu7gP/SVaRFMfrhySJawygqzpCQoV0HYuRp+aB
    2S/uVNE0h8bHEq0rINtN/gavF+7B4OKaI3K2qkvO1FlpUD3LeFsVtmGbCMLJaX3Q
    GuK5f7jiK0xkchf3wCJfanNdrMnzw5Nw687ItFYGhPkDl865Y0 z/96iu0KklDvhF
    /4nOOAxGkTg=
    =n8/b
    -----END PGP SIGNATURE-----


  3. Re: samba4: machine and user accounts

    Andrew Bartlett wrote:
    > Sorry about the bum steer - it turns out this remains a problem with the
    > current GIT tree.
    >
    > If you run:
    >
    > [abartlet@naomi source]$ cd //data/samba/samba4/prefix/modules/ldb/
    > [abartlet@naomi ldb]$ ln -s ildap.so ldap.so
    > [abartlet@naomi ldb]$ ln -s ildap.so ldapi.so
    > [abartlet@naomi ldb]$ ln -s ildap.so ldaps.so
    >
    > Then this will fix it, until you run 'make install' again. Jelmer
    > promises to fix this sometime soon...
    >

    Kerching!

    Thanks for the information, it worked well. No worries on the bum steer.


  4. Re: samba4: machine and user accounts

    Ok, got time to reprovision, replaced source/setup/schema.ldif with the
    extracted one from the domain.

    dsdb/schema/schema_init.c:431: 'msExchMailboxManagerReportRecipient':
    unable to map attributeID 1.2.840.113556.1.4.7000.102.50076:
    WERR_DS_NO_MSDS_INTID

    I picked a random oid from the the original schema.ldif to find if
    there's any lookup table or hard coded list, and I didn't find anything.

    Any suggestions to where to go next?


  5. Re: samba4: machine and user accounts

    Mike Wilkinson schrieb:
    > Ok, got time to reprovision, replaced source/setup/schema.ldif with the
    > extracted one from the domain.
    >
    > dsdb/schema/schema_init.c:431: 'msExchMailboxManagerReportRecipient':
    > unable to map attributeID 1.2.840.113556.1.4.7000.102.50076:
    > WERR_DS_NO_MSDS_INTID
    >
    > I picked a random oid from the the original schema.ldif to find if
    > there's any lookup table or hard coded list, and I didn't find anything.
    >
    > Any suggestions to where to go next?


    It's in the prefixMap attribute,
    see setup/provision_schema_basedn_modify.ldif.

    I think we need to autogenerate the base64 encoded
    based on some plain text source, maybe a simple file
    like this:

    0x00000000:1.2.3.4.1
    0x00010000:1.2.3.4.2
    0x00020000:1.2.3.4.3
    ....

    What we also need is to implement the schema master role
    completely, so that the schema can we updated at runtime
    and a new mapping is created, but first we need to write
    some tests to see how windows handles that.

    Note the prefixMapping attribute is not exposed via LDAP
    from windows hosts, the content is only accessable via the
    DsGetNCChanges() (but not as raw blob how it is stored on the database).

    metze


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFIN7kxm70gjA5TCD8RAna3AKC19mslFdaqkrNEwexGKT jf0ZfmjQCgx3K/
    c6Qa6cTUCQZx3NdmEGkW5ek=
    =YeUe
    -----END PGP SIGNATURE-----


  6. Re: samba4: machine and user accounts

    Stefan (metze) Metzmacher wrote:
    > It's in the prefixMap attribute,
    > see setup/provision_schema_basedn_modify.ldif.
    >
    > I think we need to autogenerate the base64 encoded
    > based on some plain text source, maybe a simple file
    > like this:
    >
    > 0x00000000:1.2.3.4.1
    > 0x00010000:1.2.3.4.2
    > 0x00020000:1.2.3.4.3
    > ....
    >
    > What we also need is to implement the schema master role
    > completely, so that the schema can we updated at runtime
    > and a new mapping is created, but first we need to write
    > some tests to see how windows handles that.
    >
    > Note the prefixMapping attribute is not exposed via LDAP
    > from windows hosts, the content is only accessable via the
    > DsGetNCChanges() (but not as raw blob how it is stored on the database).
    >

    I've spent hours with gdb trying to work out what the encoding is
    supposed to be, the only thing I can see for sure are the header and the
    last few bytes of the final oid. It seems likely that we can't replace
    AD with samba4 at this point, thanks for any input up to now.


  7. Re: samba4: machine and user accounts

    On Tue, 2008-05-27 at 21:14 -0400, Mike Wilkinson wrote:
    > Stefan (metze) Metzmacher wrote:
    > > It's in the prefixMap attribute,
    > > see setup/provision_schema_basedn_modify.ldif.
    > >
    > > I think we need to autogenerate the base64 encoded
    > > based on some plain text source, maybe a simple file
    > > like this:
    > >
    > > 0x00000000:1.2.3.4.1
    > > 0x00010000:1.2.3.4.2
    > > 0x00020000:1.2.3.4.3
    > > ....
    > >
    > > What we also need is to implement the schema master role
    > > completely, so that the schema can we updated at runtime
    > > and a new mapping is created, but first we need to write
    > > some tests to see how windows handles that.
    > >
    > > Note the prefixMapping attribute is not exposed via LDAP
    > > from windows hosts, the content is only accessable via the
    > > DsGetNCChanges() (but not as raw blob how it is stored on the database)..
    > >

    > I've spent hours with gdb trying to work out what the encoding is
    > supposed to be


    It is described in drsblobs.idl

    Given that the table is not accessible from windows, I am at a loss as
    to why Metze chose a binary encoding. Even so, building a text
    import/export system (along the lines of the one used for security
    descriptors and SIDs, both of which are also binary) should not be
    difficult.

    > , the only thing I can see for sure are the header and the
    > last few bytes of the final oid. It seems likely that we can't replace
    > AD with samba4 at this point, thanks for any input up to now.


    I'm sorry we have not been able to make this work for you in the
    timeframe required. If you wish to try this again in future, we would
    very much appriciate the chance to assist, as it is real world
    deployments that will make Samba4 stronger.

    Thanks,

    Andrew Bartlett

    --
    Andrew Bartlett
    http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBIPMgkz4A8Wyi0NrsRAt6eAJ9oQ3rwGiamHv++rqK7Jp U0g6a4fACfRyY0
    grZR0tpdV7hmP7yuHTEvw7I=
    =YqDK
    -----END PGP SIGNATURE-----


  8. Re: samba4: machine and user accounts

    Mike Wilkinson schrieb:
    > Stefan (metze) Metzmacher wrote:
    >> It's in the prefixMap attribute,
    >> see setup/provision_schema_basedn_modify.ldif.
    >>
    >> I think we need to autogenerate the base64 encoded
    >> based on some plain text source, maybe a simple file
    >> like this:
    >>
    >> 0x00000000:1.2.3.4.1
    >> 0x00010000:1.2.3.4.2
    >> 0x00020000:1.2.3.4.3
    >> ....
    >>
    >> What we also need is to implement the schema master role
    >> completely, so that the schema can we updated at runtime
    >> and a new mapping is created, but first we need to write
    >> some tests to see how windows handles that.
    >>
    >> Note the prefixMapping attribute is not exposed via LDAP
    >> from windows hosts, the content is only accessable via the
    >> DsGetNCChanges() (but not as raw blob how it is stored on the database).
    >>

    > I've spent hours with gdb trying to work out what the encoding is
    > supposed to be, the only thing I can see for sure are the header and the
    > last few bytes of the final oid. It seems likely that we can't replace
    > AD with samba4 at this point, thanks for any input up to now.


    The encoding is defined in source/librpc/idl/drsblobs.idl
    look for prefixMapBlob.

    And a description of how the mapping works is in
    source/librpc/idl/drsuapi.idl see the large comment
    above drsuapi_DsReplicaOID.

    metze






    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFIPQV4m70gjA5TCD8RAnkyAJ92eLph0wgJ2AjXWDfkIl i2KeivNACeN42V
    eCpjJcOcyU4IDxbY6HQQGCI=
    =Kvmv
    -----END PGP SIGNATURE-----


  9. Re: samba4: machine and user accounts

    Andrew Bartlett schrieb:
    > On Tue, 2008-05-27 at 21:14 -0400, Mike Wilkinson wrote:
    >> Stefan (metze) Metzmacher wrote:
    >>> It's in the prefixMap attribute,
    >>> see setup/provision_schema_basedn_modify.ldif.
    >>>
    >>> I think we need to autogenerate the base64 encoded
    >>> based on some plain text source, maybe a simple file
    >>> like this:
    >>>
    >>> 0x00000000:1.2.3.4.1
    >>> 0x00010000:1.2.3.4.2
    >>> 0x00020000:1.2.3.4.3
    >>> ....
    >>>
    >>> What we also need is to implement the schema master role
    >>> completely, so that the schema can we updated at runtime
    >>> and a new mapping is created, but first we need to write
    >>> some tests to see how windows handles that.
    >>>
    >>> Note the prefixMapping attribute is not exposed via LDAP
    >>> from windows hosts, the content is only accessable via the
    >>> DsGetNCChanges() (but not as raw blob how it is stored on the database).
    >>>

    >> I've spent hours with gdb trying to work out what the encoding is
    >> supposed to be

    >
    > It is described in drsblobs.idl
    >
    > Given that the table is not accessible from windows, I am at a loss as
    > to why Metze chose a binary encoding.


    I just reused the allready existing structure
    drsuapi_DsReplicaOIDMapping_Ctr and added some wrapping arround it to
    correctly autodetect this format in case it appears that we to use
    the same format that windows uses (which is unknown).

    metze


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFIPQhLm70gjA5TCD8RAswMAJ9K1YHDjnxMsKSG6JoQTo 1apsXIqACgmvjZ
    t0vTCRiubqv6MdjhXCY8Kb8=
    =Xq+g
    -----END PGP SIGNATURE-----


  10. RE: samba4: machine and user accounts

    Hi,

    > I'm sorry we have not been able to make this work for you in the
    > timeframe required. If you wish to try this again in future, we would
    > very much appriciate the chance to assist, as it is real world
    > deployments that will make Samba4 stronger.


    I decided to install a Samba4 server at home on a real machine to do some
    tests. I currently joined only my laptop to the domain (XP SP3), I have a
    few things to fix with DHCP and DNS, then I'll be able to join other
    machines, real ones, or virtual machines in order to test several OS.

    I may also test OpenChange in a near future.

    (I'm sometimes on IRC as hotnuma)

    Manu.


  11. Re: samba4: machine and user accounts

    Andrew Bartlett wrote:
    > It is described in drsblobs.idl
    >
    > Given that the table is not accessible from windows, I am at a loss as
    > to why Metze chose a binary encoding. Even so, building a text
    > import/export system (along the lines of the one used for security
    > descriptors and SIDs, both of which are also binary) should not be
    > difficult.
    >

    Well I saw how it's represented in memory, that'd be a joy to work with,
    it's the in-directory copy that's foxed me. I'll have a quick look at
    the SIDs tools, see if they're using the same encoding method, and maybe
    give it another go, but time's pressing now so it'll be quick.
    > I'm sorry we have not been able to make this work for you in the
    > timeframe required. If you wish to try this again in future, we would
    > very much appriciate the chance to assist, as it is real world
    > deployments that will make Samba4 stronger.
    >

    It's not a biggie, although it would have been nice to put windows out
    of the back office completely. I think it's just a case of too much too
    soon. I've got another couple of bugs to post, so at the very least it
    was good for reporting those.


  12. Re: samba4: machine and user accounts

    On Wed, 2008-05-28 at 10:02 -0400, Mike Wilkinson wrote:
    > Andrew Bartlett wrote:
    > > It is described in drsblobs.idl
    > >
    > > Given that the table is not accessible from windows, I am at a loss as
    > > to why Metze chose a binary encoding. Even so, building a text
    > > import/export system (along the lines of the one used for security
    > > descriptors and SIDs, both of which are also binary) should not be
    > > difficult.
    > >

    > Well I saw how it's represented in memory, that'd be a joy to work with,
    > it's the in-directory copy that's foxed me. I'll have a quick look at
    > the SIDs tools, see if they're using the same encoding method, and maybe
    > give it another go, but time's pressing now so it'll be quick.


    I didn't mean for you do write it. I'll see what I can do today - the
    code I'm looking to match is in lib/ldb-samba/ldif_handlers.c

    The 'ldif formatted' versions of these structures are human-readable
    strings. See for example how ldif_read_objectSid parsing the
    string-form SID, and ldif_write_objectSid creates the human-readable
    version.

    If we create functions for these, then we should be able to change the
    LDIF to a human-readable structure (possibly in another file, then then
    subbed in as base64 by the provision script).

    > > I'm sorry we have not been able to make this work for you in the
    > > timeframe required. If you wish to try this again in future, we would
    > > very much appriciate the chance to assist, as it is real world
    > > deployments that will make Samba4 stronger.
    > >

    > It's not a biggie, although it would have been nice to put windows out
    > of the back office completely. I think it's just a case of too much too
    > soon. I've got another couple of bugs to post, so at the very least it
    > was good for reporting those.


    Thanks.

    Andrew Bartlett

    --
    Andrew Bartlett
    http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBIPdzKz4A8Wyi0NrsRAocIAKCUjWmpSYhX8eY6V+1knf fVHiNdRwCcDIHT
    FXfmmO+//IT4steOHOjIOXk=
    =2Bqu
    -----END PGP SIGNATURE-----


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2