AFP548 Changing the world one server at a time.

st3w13

Forum Replies Created

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • in reply to: OD Integration Error with Kerio Mail Server #381081
    st3w13
    Participant

    Unfortunately, if kinit fails on the OD master then nothing for this user will work.

    In Workgroup Manager, create a new user to test with. Create test2 & assign some password & save. Then do “kinit test2” in Terminal. When prompted for the user’s password, enter it & press return. Ideally you just return back to the shell prompt which means the OD master successfully authenticated the user. (You can enter “kdestroy” to remove the ticket you just created with kinit.)

    Now go to your Kerio box & do the same thing. If you successfully authenticate then all that’s left is to open the Kerio admin web page & select the “test2” user from the Directory Services list & enable the account. You should then be able to login via webmail (or any other client).

    in reply to: OD Integration Error with Kerio Mail Server #381078
    st3w13
    Participant

    Hey, Kevin.

    Are you sure you have a user entry in Workgroup Manager for “test1”? What happens if you open Terminal.app & do “kinit test1” on your OD server? And on your Kerio server?

    st3w13
    Participant

    reippuert, any update? I haven’t been able to work on this issue lately but the problem persists. Any additional info would be appreciated.

    st3w13
    Participant

    reippuert, we have the same problem.

    I can replicate your error. Also, I noticed if you add the OD master first (dsconfigldap -a myod.company.com) then try to bind (dsconfigldap -fvi -a myod.company.com -c mymac -n myodconf -u directoryadmin -l admin), you’ll get an error “Computer with the name ‘mymac’ already exists” even though mymac does not have a directory entry. Provide any computer name & it errs with a similar message.

    I turned on OD debugging in Lion (with odutil set log debug) & ran these commands. With no assigned OD, I noticed this log entry:

    Node: /LDAPv3/myod.company.com - queuing request to connection - '/LDAPv3/myod.company.com:ldap:D79ACA28-BE35-4566-BF6D-131FC5C3BCBF'
    Node: /LDAPv3/myod.company.com, Module: ldap - calling request handler
    Node: /LDAPv3/myod.company.com, Module: ldap - adding superior 'top' to class list for objectclass 'apple-computer'
    Node: /LDAPv3/myod.company.com, Module: ldap - adding required attributes for objectClass 'apple-computer'
    Node: /LDAPv3/myod.company.com, Module: ldap - adding required attributes for objectClass 'top'
    Node: /LDAPv3/myod.company.com, Module: ldap - adding attribute - 'objectClass'
    Node: /LDAPv3/ldap://myod.company.com, Module: ldap - creating record with DN - cn=mymac$,cn=computers, dc=myod,dc=company,dc=com
    Node: /LDAPv3/ldap://myod.company.com, Module: ldap - Audit - Record attribute value schema error (4202) - Create record type Computers 'mymac$' node '/LDAPv3/ldap://myod.company.com'

    Executing with the OD already added I don’t notice anything unusual in the log other than “Trigger – cancelled.”

    Noticing the “cn” attribute is used & that the Search & Mappings > Default Attribute Types is empty (Leopard & Snow Leopard show entries here) I attempted to recreate them, especially RecordName = cn. But alas, the custom settings do not get saved. (If you create a new record & attributes, however, they do save. It’s only the Default Attribute Types record that appears broken, & you can’t delete & recreate it either.)

    I’m still looking for a solution. But figured I would to add to you post in the hope it may be helpful to you.

Viewing 4 posts - 1 through 4 (of 4 total)