Command line configuration of LDAP settings

SVM-IT
New Contributor III

I'm looking for documentation on how to configure LDAP settings via the command line because I'd like to create a script. The guides I've found so far have been too dense to be useful.

1 ACCEPTED SOLUTION

stevewood
Honored Contributor II
Honored Contributor II

@SVM-IT

I finally had a minute to look at this, and I think you're correct. I think that since you are not binding you can just collect the plist files and drop them in their proper spots. I followed your guidelines, and those of the site you linked to, on a test machine and afterwards used dsconfigad -show to see if I could export the xml or see anything. Nothing came up. So I dug into /Library/Preferences/OpenDirectory and I could see the plists that were changed.

Sorry for delaying you, if I did, I just know how copying those plists can mess up binding. I've had to deal with that in a couple of agencies I help support.

View solution in original post

6 REPLIES 6

easyedc
Valued Contributor II

Did you check out Apple's documentation here?

EXAMPLES
     Adding a computer to a Directory:

     dsconfigad -add domain.ads.example.com -computer ThisComputer -username "administrator" -ou
     "CN=Computers,OU=Engineering,DC=ads,DC=example,DC=com"

     Giving a set of groups administrative access to the local computer:

     dsconfigad -groups "DOMAINdomain admins,FORESTenterprise admins,DOMAINdesktop techs"

SVM-IT
New Contributor III

I looked at the documentation and it was helpful, but what I ended up doing is using Composer to capture the changes while I made them through the GUI. That had the advantage of identifying the plists that are used to apply the LDAP configuration, and created a package that I can deploy to workstations.

stevewood
Honored Contributor II
Honored Contributor II

@SVM-IT I would caution you heavily against packaging up the plist files from a Composer capture of the domain binding process. I'm assuming what you did was to use Directory Utility to bind a machine and then captured the plist files generated with Composer.

The problem with that method is that it also captures the computer record info from AD. So when you deploy that to your fleet, every machine will bind as the same machine identity. This will effectively break binding for your machines.

If you need to script, either use dsconfigad as @easyedc recommended, or setup Binding settings in your Jamf Pro server, setup a policy that applies those settings, and then call the policy from a script.

If you need specific settings configured, list out those settings in this post and I'm pretty sure someone can help you craft the proper script syntax for a dsconfigad call.

SVM-IT
New Contributor III

I appreciate the warning. I'm still in the testing phase so the guidance is timely.

Some of our Mac Minis are set up in podiums and prior to Casper we configured them to use Kerberos for authentication and LDAP for authorization, as described in a Penn State wiki: https://wikispaces.psu.edu/display/clcmaclinuxwikipublic/macOS+Authentication+Configuration

Now that we have Casper I’d like to automate the configuration of the Mac Minis and the part I’m working on now is “Configuration of LDAP for Authorization”. Since we’re not using LDAP for authentication I’m thinking it might dodge the binding problem.

What I’m trying to duplicate in LDAP configuration by using Composer are the following changes I've been making via the System Preferences/Users & Groups GUI:

In the Server Name or IP Address field enter: “ldap.domain.com” - Encrypt using SSL: NOT CHECKED - Use for authentication: NOT CHECKED - Use for contacts: CHECKED

On the “ldap.domain.com” line, change the LDAP Mappings pop-up menu to "Custom", which will display a new window to configure the Search and Mappings.
Select the Connection tab and change these settings: Check (enable) the Encrypt using SSL option Change the Use custom port to 636
Select the "Search & Mappings" tab, if it's not already the active tab. Click the "Add..." button under the left window, Record Types and Attributes. Click the 'Record Types' radio button Scroll down and select (click) 'Users' Click the 'OK' button to add this Attribute Type Select (click) the 'Users' record type you just added Click the 'Add...' button that is located under the right pane (Map to 'any' items in list) In the box that appears, type 'inetOrgPerson' (without the quotes). Set the Search base for the 'Users' record type: Search base: ou=People, dc=domain, dc=com Search In: all subtrees
Next, add the required LDAP attributes to the 'Users' Record. Click the 'Add...' button under the left pane (Record Types and Attributes) Click the 'Attribute Types' radio button, Select “AuthenticationAuthority” and set to “uid”

Add ldap.domain.com to the Search Path: - Click "Search Policy" - Set the "Search:" drop-down menu to "Custom path" - Click the "+" Button - Select "/LDAPV3/ldap.domain.com” and click the "Add" button. - Click the "Apply" button. - Quit out of Directory Utility.

I’d like to know if the above approach avoids the binding problem, although even if it does, any examples of how to configure the above using dsconfigad would be appreciated. Handling this via a script seems like a better approach long term.

Thanks.

Seth

stevewood
Honored Contributor II
Honored Contributor II

@SVM-IT

I finally had a minute to look at this, and I think you're correct. I think that since you are not binding you can just collect the plist files and drop them in their proper spots. I followed your guidelines, and those of the site you linked to, on a test machine and afterwards used dsconfigad -show to see if I could export the xml or see anything. Nothing came up. So I dug into /Library/Preferences/OpenDirectory and I could see the plists that were changed.

Sorry for delaying you, if I did, I just know how copying those plists can mess up binding. I've had to deal with that in a couple of agencies I help support.

SVM-IT
New Contributor III

Much obliged.