Forum Replies Created

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • in reply to: Yet another AD binding problem #374131

    Try opening port 464 (UDP) to the domain controller, as this is the port that kpassword5 communicates over.

    See also:


    in reply to: AD Kerberos working–SSO to AFP not working #373941

    Check your clock skew, time zone, and dns forward and reverse for

    in reply to: Assistance for AD Noob, please! #373940

    Since the home directory attribute is synthesized by the AD plugin, you can use augmented records to change it. It would then only be applied to the Macs. See page 43 (Chapter 9) at:

    Click to access Leveraging_AD_on_MOSXS_2.1.pdf

    in reply to: dsattrtypestandard vs dsattrtypenative #373939

    To understand it better, open up Directory Utility and go to Search and Mappings of a LDAP config. Under the Record Types and Attributes, you’ll see the “Standard” Record Types and Attributes. If you select a top level Record (like Users), you’ll see the objectClasses that are mapped to this Record Type. So when DirectoryService wants to find a user, it knows to search in LDAP for objects of type “inetOrgPerson, posixAccount, etc”, and starts searching in the DN in “Search base”. Once the results come back, the “native” LDAP attributes (such as uidNumber) are mapped to standard attributes (“UniqueID”). The inspector in Workgroup Manager allows you to see what is directly in LDAP (“Native”) and how this being mapped to DirectoryServices (“Standard”). If you had something mapped incorrectly, you could easily see that.

    in reply to: Importing user accounts #373938

    When importing, WGM should display a sheet that allows you to map fields. Are you saving the user list as something like tab delimeted or comma delimited?

    in reply to: Access configuration for Open Directory #373937

    As of 10.5, you need to edit the directory access controls (DACLs) and other slapd setting directly in cn=config (not the same as cn=config,dc=,dc=) and changes take effect immediately.

    The replicas should be able to handle authentication. In fact, you should not need to bind the clients directly to the OD Replica, as the clients should be able to figure out the fastest replica based on ping times. Replicas have a copy of password server as well as the kerberos database. Verify that in /Library/Preferences/DSLDAPv3PlugInConfig.plist you have a Replica Hostname List that lists all the replicas by IP address. Sniff the network to see where the client is authenticating. If you bind directly to the replica, how is it failing? Login window shake?

    in reply to: OD Access Control in Leopard Server #373935

    you need to edit cn=config directly and the changes are applied live. Grab an LDAP editor that allows read/write to an ldap store, like LDAPBrowser. When you specify the DN, do not specify it with your base DN, but rather just “cn=config” (not cn=config,dc=example,dc=com). Select oldDatabase={1}bdb and look at the olcAccess attributes. If you modify/add this attribute, it will immediately take effect (don’t have to HUP slapd).

    As for modifying the ACL, find one that is similar, duplicate it and modify it.

    Note that you could use LDIF files to modify these attributes, but LDAPBrowser allows you a GUI way to do it.


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