Last week, I gave a presentation on criteria for evaluating partners, managing revenue streams and partner channel programs. The presentation, given on May 4th, is available below. The file is ACES_Partners
You can now find an ldif to csv converter done in Swift on my Github account at krypted/swift-ldif-csv. The project is pretty easy to use, simply define an input ldif file using the first positional parameter and then a csv using the -csv option. You can also use -a to define the attributes to migrate. Enjoy, fork, add, etc. For a quick download of the binary, click here.
The LDIFDE utility exports and imports objects from and to Active Directory using the ldif format, which is kinda’ like csv when it gets really drunk and can’t stay on one line. Luckily, ldif can’t drive. Actually, each attribute/field is on a line (which allows for arrays) and an empty line starts the next record. Which can make for a pretty messy looking file the first time you look at one. The csvde command can be used to export data into the csv format instead. In it’s simplest form the ldifde command can be used to export AD objects just using a -f option to specify the location (the working directory that we’re running the ldifde command from if using powershell to do so or remove .\ if using a standard command prompt):
ldifde -f .\ADExport.ldfThis exports all attributes of all objects, which overlap with many in a target Active Directory and so can’t be imported. Therefore, you have to limit the scope of what you’re exporting, which you can do in a few ways. The first is to only export a given OU. To limit, you’ll define a dn with a -d flag followed by the actual dn of the OU you’re exporting and then you’d add a -p for subtree. In the following example we’ll export all of the objects from the sales OU to the SalesOUExport.ldf file:
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -f .\SalesOUExport.ldfRestoring objects still results in an error that the server is “Unwilling To Perform” the import because “The modification was not permitted for security reasons.” Basically, this just means “hey I’m not going to import into some of the fields that I know I have to reserve for objects managed by the system, such as creation date (whencreated), last changed date (whenchanged), etc. So we can take some of these and omit them from our export. You can use ADMT or just look at an ldif or csv file to determine which attributes from the schema that you think need to be omitted, but at a minimum it should include objectguid, uSNCreated, uSNChanged, whencreated and when changed (and a lot of the Exchange attributes if you’ve extended the schema for your forest). To omit use the -o and enclose the omitted attributes in parenthesis. In the following example, we’ll export to the SalesOUExportO.ldf file, and add the -o flag to the previous command:
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -o "objectguid,uSNCreated,uSNChanged,whencreated,whenchanged" -f .\SalesOUExportO.ldfYou can also omit using the -m flag, which includes only the essential attributes, so we’ll add that to the command as well:
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -o "objectguid,uSNCreated,uSNChanged,whencreated,whenchanged" -m -f .\SalesOUExportO.ldfUse the -l option to limit the attributes being exported to only those specified. The -r option restricts the export to a given category or class. For example, if we only wanted to export users, we can restrict to objectClass-User
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -r "(objectClass=user)" -o "objectguid,uSNCreated,uSNChanged,whencreated,whenchanged" -m -f .\SalesOUExportOM.ldfNow I’m feeling like we have a good restricted set of data that we’re moving. Let’s go ahead and give importing a shot on a target server. To do so, we’ll just use -i to specify this is an import, followed by -k to say “don’t stop if you have a problem with just one record”, -f to define a file and -j to write a log. We’ll use the working directory for the file path and the log path, assuming this is being done by calling the .exe from within powershell:
ldifde -i -k -f .\SalesOUExportOM.ldf -j .\Once complete, the exported objects should appear once you close and re-open Active Directory Users and Computers. You can also export one object, then programmatically create objects in an ldif file as needed by importing them into Active Directory using ldifde.
You can use the Unlock-ADAccount PowerShell commandlet to unlock an Active Directory account. This can be helpful, for example, as a Self Service option in a Casper server. To do so, run the Unlock-ADAccount commandlet followed by the -Identity option and then the SamAccountName:
Unlock-ADAccount -Identity CharlesEdge
You can disable an Active Directory account using the Disable-ADAccount PowerShell commandlet. To do so, use the -Identity option along with the SAMAccountName of the account to disable. Here, we’ll use the SAMAccountName of CharlesEdge:
Disable-ADAccount -Identity CharlesEdgeThe account can then be re-enabled using the Enable-ADAccount commandlet using the same command structure:
Enable-ADAccount -Identity "CharlesEdge"
The options for Open Directory continue to get more refined, aligning with opendirectoryd. The odutil command is becoming more and more useful with each version of OS X. Let’s inspect the directory service cache, using odutil with the show verb and the cache option:
odutil show cacheYou can also view statistics for opendirectoryd using that show verb but with the statistics option:
odutil show statisticsAnd to see everything, use odutil with the show verb and the all option to get plenty of data to grep through:
odutil show allThe final show option we’ll look at is configuration. Here, you will also need to feed a directory nodename into the command:
odutil show configuration /SearchNow, /Search is a node but there are a lot. You can use show with nodes to see a listing of all the nodes:
odutil show nodesYou can then see which pids have references to opendirectoryd as well as the nodenames, reference IDs, and session IDs. All of this can be very helpful when troubleshooting Open Directory issues. One thing I find I do pretty frequently is resetting statistics then repeating a process that is causing a problem so I can view only the updated statistics. To do so:
odutil reset statisticsYou can also disable statistics (I’ve seen them create performance concerns:
odutil set statistics offOr to turn them back on:
odutil set statistics onOnce upon a time you could killall DirectoryService with a -usr level to set various logging levels. With opendirectoryd, we can still do that, but it’s less cludgy with odutil. Here, we’ll set the logging level as detailed as we can get:
odutil set log debugOther levels, in ascending order of verbosity, include alert, critical, error, warning, notice, and info.
You can destroy an LDAP server using the Server app (and still using slapconfig -destroyldapserver). To do so, open the Server app and click on Open Directory. Then click on the Open Directory server in the list of servers. When prompted to destroy the LDAP Master, click on Next. When asked if you’re sure, click Continue. When asked if you’re really, really sure, click Destroy. Wait.
You can gracefully stop Windows processes using the Stop-Process command let. For example, to stop Chrome:
Stop-Process -Name ChromeOr to stop it by ID. To locate the ID of a process, use get-process:
get-process ChromeYou can then use the -ID operator to stop the process:
Stop-Process -ID 6969Kill is a command that all Mac and Unix admins know. It’s similar to Stop-Process, except it’s anything but graceful. And you use the -processname option to stop a process:
kill -processname calc
There are 3 registry keys that admins in the Windows world use to enable automatic logins, often required for deployments that require a logged in user to setup user environments, such as configuring app deployments as part of a mass deployment. The required keys in the registry are: Continue reading Enable AutoAdminLogon For Windows Deployments