Tiny Deathstars of Foulness

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. Screen Shot 2016-05-09 at 3.26.00 PM The file is ACES_Partners  

May 12th, 2016

Posted In: Active Directory, Apple Configurator, Bushel

Tags: , , , , ,

May 4th, 2016

Posted In: Active Directory, Windows Server

Tags: ,

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.ldf This 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.ldf Restoring 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.ldf You 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.ldf Use 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.ldf Now 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.

February 27th, 2016

Posted In: Active Directory

Tags: , , , , , , , ,

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 cache You can also view statistics for opendirectoryd using that show verb but with the statistics option: odutil show statistics And to see everything, use odutil with the show verb and the all option to get plenty of data to grep through: odutil show all The 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 /Search Now, /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 nodes You 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 statistics You can also disable statistics (I’ve seen them create performance concerns: odutil set statistics off Or to turn them back on: odutil set statistics on Once 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 debug Other levels, in ascending order of verbosity, include alert, critical, error, warning, notice, and info.

July 10th, 2015

Posted In: Active Directory, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , ,

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. Screen Shot 2015-01-16 at 11.22.15 PM When prompted to destroy the LDAP Master, click on Next. Screen Shot 2014-12-15 at 10.09.56 PM When asked if you’re sure, click Continue. Screen Shot 2014-12-15 at 10.10.00 PM When asked if you’re really, really sure, click Destroy. Screen Shot 2014-12-15 at 10.10.03 PM Wait.

January 19th, 2015

Posted In: Active Directory, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , ,

You can gracefully stop Windows processes using the Stop-Process command let. For example, to stop Chrome: Stop-Process -Name Chrome Or to stop it by ID. To locate the ID of a process, use get-process: get-process Chrome You can then use the -ID operator to stop the process: Stop-Process -ID 6969 Kill 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

January 12th, 2015

Posted In: Active Directory, Windows Server, Windows XP

Tags: , , , , , ,

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: (more…)

December 8th, 2014

Posted In: Active Directory, Mass Deployment, Microsoft Exchange Server, VMware, Windows Server, Windows XP

Next Page »