en-US/about_OpenADComparison.help.txt
TOPIC
about_openadcomparison SHORT DESCRIPTION While this module follows a similar setup to the Microsoft ActiveDirectory module there are some differences. This document will attempt to explain those differences and why they exist. LONG DESCRIPTION On a technical perspective one of the key differences with this module compared to the `ActiveDirectory` module is that `PSOpenAD` uses LDAP for communication with the domain controller. The `ActiveDirectory` module uses a SOAP based API to communicate through the Active Directory Web Services protocol. In practical terms, the main difference will be the port used for communication from the client to the domain controller, LDAP runs over port `389` or `636` (TLS). LDAPFILTER VS FILTER The `Get-OpenAD ` cmdlets do not implement the `-Filter` property that exists on the `Get-AD ` cmdlets. There are no plans on implementing the conversion that exists for `-Filter` as the alternative `-LDAPFilter` is available. The docs for Active Directory: LDAP Syntax Filters cover a lot of the various filters that are available and how they are formatted. OUTPUT PROPERTIES ON GET OPERATIONS There are a few differences in the output object that the `Get-OpenAD ` cmdlets have compared to their `Get-AD ` counterparts. Some of the key differences are: + The requested attributes are returned in PascalCase and not the camelCase format the LDAP attributes are written as While the ActiveDirectory module does this for some return properties there are still some others that use the camelCase format. The PSOpenAD module will always set the return properties to be in the PascalCase format. + Properties explicitly requested but not set on the underlying object will still be present in the output object The PSOpenAD cmdlets will always return a note property for any property that was explicitly requested. This ensures that the output objects from a cmdlet call have a consistent set of properties rather than what was originally requested. Return objects can still have a dynamic set of properties as things like `-Properties *` only return properties for attributes that have a set value. + Using `-Properties *` will return less The ActiveDirectory module hard codes a set of properties to always return when requesting `-Properties *` whereas `PSOpenAD` open return the LDAP attributes that have a set value. To ensure a property is always present on the output object it is recommended to explicitly request that property. + Aliased properties like `lastLogonDate` are not returned Certain properties that the ActiveDirectory module return are not present in the PSOpenAD output objects. PSOpenAD is designed to return the LDAP attributes as they are without aliases, with some small exceptions. + Some property types are different PSOpenAD will convert the LDAP attribute values requested to .NET types that better align with what the value represents. Some of the types that will be used are + Interval values that represent a date will become [DateTimeOffset](https://docs.microsoft.com/en-us/dotnet/api/system.datetimeoffset?view=net-6.0 * Interval values that represent a time span will become TimeSpan * Known enum values will be represent by an enum rather than the raw integer value * GUID values will become Guid * Security Identifiers will become a custom Security Identifier class that works on both Windows and non-Windows * Translating these values back to an account name is only possible on Windows with `[System.Security.Principal.SecurityIdentifier]::new($obj.ObjectSid).Translate([System.Security.Principal.NTAccount])` * Security Descriptors will become a custom security descriptor class that works on both Windows and non-Windows This is not a complete list but should be the main ones encountered when using the PSOpenAD modules. TAB COMPLETION SUPPORT To make the cmdlets easier to use and be more discoverable, the `Get-OpenAD*` cmdlets offer tab completion for properties like `-Properties`. For tab completion to work there has to have been at least 1 session created by the client so the schema is cached for the completion. Once the schema has been cached tab completion can be used to discover the various properties that are valid for the `Get-OpenAD*` cmdlet that is being used. |