Beast's Domain Mac OS
I have Mac OS X clients bound to an AD domain right now. We are migrating to a new domain. The 2 AD domains are up and running in production now. They are not in the same forest, but rather they are independent forests themselves. The 2 AD domains have a full trust between themselves. By the end of the year the old AD domain will be deprecated and removed.
There will be an interim period where some of our file servers & storage will live in the new domain before all my users are migrated. While users can resolve the new file servers in the new domain via DNS, I cant get Kerberos to work for those servers. Thus users are challenged to authenticate manually.
My Mac OS X clients are bound to the primary AD domain (lets call it domain A).
'Allow authentication from any domain in the forest' is enabled in the DS GUI Utility. I dont see any magic options in the dsconfigad command line utility. the 'namespace' switch looks interesting, but I can find an example of how to use it.
I can ping and resolve all hosts in Domain B. DNS is not an issue.
All servers in both domains point to the the same NTP time servers. No time drifting here.
The DCs in both Domain A and Domain B are KDCs and each domain has a Kerberos realm for its own domain. Not sure if this is default settings or not.
I am getting a valid TGT from the DCs in Domain A as expected.
I have a mix of 10.5.8 and 10.6.4 Macs in production. They behave exactly the same.
All user accounts still live in Domain A. They have not been migrated or moved to Domain B yet. Same for the computer records in AD.
I noticed that right now the TGT I get from the KDC/DC in Domain A is not fordwarable. Not sure what this means.
I can manually reuest a TGT from both realms/domains via the Apple Ticket Viewer utility.
Kerberos works fine for all services in domain A from my Macs. Kerberos does not work when connecting to servers in Domain B.
I have a Mac bound to Domain B too for testing. It has the exact opposite problem: Kerberos works fine for all services in domain B from Mac bound to Domain B. But Kerberos does not work when conencting to servers in Domain A from Domain B.
All my Windows PCs and Linux PCs in Domain A are able to get Kerberized services to work just fine in both domains - no problems. The Mac clients are the only systems having issues with Kerberos/SSO.
Im wondering if Mac OS isn't understanding or honoring the dual-AD domain trust for some reason. Obviously I cant bind to 2 different domains.
Possible ideas:
Build 1 Kerberos realm for both domains and not have 2 realms? Im not sure is Windows DC servers can do this or not. Not sure how MS KDC severs work in AD.
Tell Kerberos on the Mac clients to be able to forward their TGT to other realms/domains when connecting to Kerberized services?
Enable some sort of namespace support in the DS plugin? I cant find an example of how to do this correctly.
Directory Utility User Guide
This is a Tier 3 zone accessed via the 'arms' of Argath and outer reaches of Sarith. It's a lush, wild land where the beasts rule: It's all about the hunt and in order to survive, a beast must kill. When there is no prey, the predators will hunt predators. Script to enable SSH, rename computer, and join AD Domain on Mac (Mountain Lion) Here is a script we are using as a post-installation task to enable SSH, set the computer name, and then join the computer to our Active Directory managed domain. Currently seeking micro/ tiny apartment opportunities!
Important: With the advanced options of the Active Directory connector, you can map the macOS unique user ID (UID), primary group ID (GID), and group GID attributes to the correct attributes in the Active Directory schema. However, if you change these settings later, users might lose access to previously created files.
Bind using Directory Utility
In the Directory Utility app on your Mac, click Services.
Click the lock icon.
Enter an administrator’s user name and password, then click Modify Configuration (or use Touch ID).
Select Active Directory, then click the “Edit settings for the selected service” button .
Enter the DNS host name of the Active Directory domain you want to bind to the computer you’re configuring.
The administrator of the Active Directory domain can tell you the DNS host name.
If necessary, edit the Computer ID.
The Computer ID, the name the computer is known by in the Active Directory domain, is preset to the name of the computer. You can change it to conform to your organization’s naming scheme. If you’re not sure, ask the Active Directory domain administrator.
Important: If your computer name contains a hyphen, you might not be able to bind to a directory domain such as LDAP or Active Directory. To establish binding, use a computer name that does not contain a hyphen.
If the advanced options are hidden, click the disclosure triangle next to Show Options. You can also change advanced option settings later.
(Optional) Select options in the User Experience pane.
See Set up mobile user accounts, Set up home folders for user accounts, and Set a UNIX shell for Active Directory user accounts.
(Optional) Select options in the Mappings pane.
See Map the group ID, Primary GID, and UID to an Active Directory attribute.
(Optional) Select options in the Administrative pane.
Prefer this domain server: By default, macOS uses site information and domain controller responsiveness to determine which domain controller to use. If a domain controller in the same site is specified here, it’s consulted first. If the domain controller is unavailable, macOS reverts to default behavior.
Allow administration by: When this option is enabled, members of the listed Active Directory groups (by default, domain and enterprise admins) are granted administrative privileges on the local Mac. You can also specify desired security groups here.
Allow authentication from any domain in the forest: By default, macOS automatically searches all domains for authentication. To restrict authentication to only the domain the Mac is bound to, deselect this checkbox.
See Control authentication from all domains in the Active Directory forest.
Click Bind, then enter the following information:
Note: The user must have privileges in Active Directory to bind a computer to the domain.
Username and Password: You might be able to authenticate by entering the name and password of your Active Directory user account, or the Active Directory domain administrator might need to provide a name and password.
Computer OU: Enter the organizational unit (OU) for the computer you’re configuring.
Use for authentication: Select if you want Active Directory added to the computer’s authentication search policy.
Use for contacts: Select if you want Active Directory added to the computer’s contacts search policy.
Click OK.
Directory Utility sets up trusted binding between the computer you’re configuring and the Active Directory server. The computer’s search policies are set according to the options you selected when you authenticated, and Active Directory is enabled in Directory Utility’s Services pane.
With the default settings for Active Directory advanced options, the Active Directory forest is added to the computer’s authentication search policy and contacts search policy if you selected “Use for authentication” or “Use for contacts.”
However, if you deselect “Allow authentication from any domain in the forest” in the Administrative Advanced Options pane before clicking Bind, the nearest Active Directory domain is added instead of the forest.
You can change search policies later by adding or removing the Active Directory forest or individual domains. See Define search policies.
Bind using a configuration profile
The directory payload in a configuration profile can configure a single Mac, or automate hundreds of Mac computers, to bind to Active Directory. As with other configuration profile payloads, you can deploy the directory payload manually, using a script, as part of an MDM enrollment, or by using a client-management solution.
Payloads are part of configuration profiles and allow administrators to manage specific parts of macOS. You select the same features in Profile Manager that you would in Directory Utility. Then you choose how the Mac computers get the configuration profile.
In the Server app on your Mac, do the following:
To configure Profile Manager, see Start Profile Manager in the macOS Server User Guide.
To create an Active Directory payload, see Directory MDM payload settings for Apple devices in Mobile Device Management Settings for IT Administrators.
If you don’t have the Server app, you can download it from the Mac App Store.
Bind using the command line
You can use the dsconfigad command in the Terminal app to bind a Mac to Active Directory.
For example, the following command can be used to bind a Mac to Active Directory:
dsconfigad -preferred <adserver.example.com> -a <computername> –domain example.com -u administrator -p <password>After you bind a Mac to the domain, you can use dsconfigad to set the administrative options in Directory Utility:
dsconfigad -alldomains enable -groups domain <admins@example.com>, enterprise <admins@example.com>Advanced command–line options
The native support for Active Directory includes options that you don’t see in Directory Utility. To see these advanced options, use either the Directory payload in a configuration profile; or the dsconfigad command–line tool.
Start reviewing the command–line options by opening the dsconfigad man page.
Computer object password interval
When a Mac system is bound to Active Directory, it sets a computer account password that’s stored in the system keychain and is automatically changed by the Mac. The default password interval is every 14 days, but you can use the directory payload or dsconfigad command–line tool to set any interval that your policy requires.
Setting the value to 0 disables automatic changing of the account password: dsconfigad -passinterval 0
Note: The computer object password is stored as a password value in the system keychain. To retrieve the password, open Keychain Access, select the system keychain, then select the Passwords category. Find the entry that looks like /Active Directory/DOMAIN where DOMAIN is the NetBIOS name of the Active Directory domain. Double-click this entry, then select the “Show password” checkbox. Authenticate as a local administrator as needed.
Namespace support
macOS supports authenticating multiple users with the same short names (or login names) that exist in different domains within the Active Directory forest. By enabling namespace support with the Directory payload or the dsconfigad command–line tool, a user in one domain can have the same short name as a user in a secondary domain. Both users have to log in using the name of their domain followed by their short names (DOMAINshort name), similar to logging in to a Windows PC. To enable this support, use the following command:
Beast's Domain Mac Os Download
dsconfigad -namespace <forest>
Download New Mac Os
Packet signing and encryption
The Open Directory client can sign and encrypt the LDAP connections used to communicate with Active Directory. With the signed SMB support in macOS, it shouldn’t be necessary to downgrade the site’s security policy to accommodate Mac computers. The signed and encrypted LDAP connections also eliminate any need to use LDAP over SSL. If SSL connections are required, use the following command to configure Open Directory to use SSL:
dsconfigad -packetencrypt ssl
Note that the certificates used on the domain controllers must be trusted for SSL encryption to be successful. If the domain controller certificates aren’t issued from the macOS native trusted system roots, install and trust the certificate chain in the System keychain. Certificate authorities trusted by default in macOS are in the System Roots keychain. To install certificates and establish trust, do one of the following:
Beast's Domain Mac Os X
Import the root and any necessary intermediate certificates using the certificates payload in a configuration profile
Use Keychain Access located in /Applications/Utilities/
Use the security command as follows:
/usr/bin/security add-trusted-cert -d -p basic -k /Library/Keychains/System.keychain <path/to/certificate/file>
Restrict Dynamic DNS
macOS attempts to update its Address (A) record in DNS for all interfaces by default. If multiple interfaces are configured, this may result in multiple records in DNS. To manage this behavior, specify which interface to use when updating the Dynamic Domain Name System (DDNS) by using the Directory payload or the dsconfigad command–line tool. Specify the BSD name of the interface in which to associate the DDNS updates. The BSD name is the same as the Device field, returned by running this command:
networksetup -listallhardwareports
When using dsconfigad in a script, you must include the clear-text password used to bind to the domain. Typically, an Active Directory user with no other administrator privileges is delegated the responsibility of binding Mac computers to the domain. This user name and password pair is stored in the script. It’s common practice for the script to securely delete itself after binding so this information no longer resides on the storage device.