Well, we have to play nicely with all of the Windows stuff that is out in the world. In the enterprise, we have to accept that we are going to have to deal with Windows Networking, particularly authentication and authorization services provided by Active Directory.

Apple has improved the integration with Windows Networking over the years but you still have to do a bunch of contortions to get a machine on the network. Note that the following is taken from multiple Apple support sites and some AI assistance.

Joining a machine into an AD domain and configuring it for network authentication requires you to bind the machine to Domain through Directory Services and then configure authentication on the local machine to connect to the AI domain.

---

1. Bind the Mac to the AD domain

macOS includes the dsconfigad tool (Active Directory connector) which allows you to bind a Mac to an AD domain from Terminal. (Apple Support)

Here’s a typical command (you’ll substitute your values):

sudo dsconfigad -add DOMAIN.COM \
    -computer "Mac-Hostname" \
    -username "BindUser" \
    -password "BindPassword" \
    -ou "OU=Computers,DC=DOMAIN,DC=COM" \
    -force

Explanation of parameters:

• -add DOMAIN.COM → The AD domain you’re joining.
• -computer "Mac-Hostname" → The name you want this Mac to appear in AD.
• -username / -password → Credentials of an AD account with rights to bind computer objects.
• -ou "…" → The organizational unit in AD where you want the computer object to reside.
• -force → Optional, for example if it was already bound previously, etc.

Other common flags you may want:

sudo dsconfigad -domain DOMAIN.COM \
     -alldomains enable \
     -groups "Domain Admins,Enterprise Admins" \
     -packetsign require \
     -packetencrypt require

This enables all domains in the forest, adds certain AD groups to the Mac’s “admin” group, and enables packet signing/encryption for LDAP/AD traffic. (Apple Support)

---

2. Enable network users to log in at the login window

Once the Mac is bound, you need to allow domain users (network accounts) to login at the macOS login window. There are GUI steps (System Preferences → Users & Groups → Login Options → “Allow network users to log in at login window”), but we can achieve this via command line/config defaults.

Command-line approach

You can use the defaults command to set a preference so that network users are allowed to login. Example:

sudo defaults write /Library/Preferences/com.apple.loginwindow ENABLEDIRLOGIN -bool true

This sets ENABLEDIRLOGIN to true, enabling directory (network/AD) users at login. (Note: this key has been used historically, though exact availability may vary across macOS versions.)

Also ensure that the login window is set appropriately (e.g., “Name & Password” rather than “List of Users”). For example:

sudo defaults write /Library/Preferences/com.apple.loginwindow SHOWFULLNAME -bool true

Then you may want to restart the loginwindow or reboot:

sudo killall loginwindow

Mobile/local account caching and mobile user accounts

This is a an important step that some sites wrongly suggest as optional. You really, really, really, really want to use dsconfigad to enable domain users to have mobile accounts. This will cache credentials locally and will permit users to login when offline from the enterprise network. Otherwise you won’t be able to login. We also strongly recommend that you do keep a separate local user for when things go wrong.

Here’s how to enable mobile accounts in MacOS via dsconfigad:

sudo dsconfigad -mobile enable -mobileconfirm disable -localhome enable

(from the gist example) (Gist)

---

3. Verification & Pitfalls

• After binding you can check current settings:

dsconfigad -show

This will display the domain, computer account, OU, mobile account settings etc. (Gist)

• Make sure DNS is correctly configured: the Mac must be able to resolve the domain controllers for your AD domain. Apple’s documentation emphasizes DNS/Kerberos/LDAP for AD integration. (Apple Support)
• If users cannot login:
• Check that “Allow network users to log in at login window” is indeed enabled (GUI or defaults).
• If after login attempt the screen just sits/spins/shakes, it may be waiting on network/LDAP/Kerberos auth. Example case discussed in Apple forums. (Apple Support Community)
• LocalAdmin vs domain group membership: If you want certain AD groups to be local admins (e.g., “Domain Admins”), you’ll include that in the binding via -groups flag. Otherwise domain user logins may succeed but the user may lack local rights.
• For macOS versions and AD interactions: some behaviors may change from version to version (especially around caching or login window UI). Always test in your environment.

CAVEAT: We admit to using AI tools to research and edit this post.

Selah.

Unity builds a lot of stuff, lots of which are files generated by the tools that shouldn’t be committed to version control.

• Create new empty 3-d project in Unity Editor
• Create a new empty repo in your GitHub account
• Use text editor to add a README.md in the root folder of your project
• Go to GitHub’s archives of .gitignore files and grab the .gitignore for Unity development.
  • Place this file in the root folder for your project
• Execute the following script:

git init
git add README.md ,gitignore
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/adamwadelewis/gallery.git
git push -u origin main

• Now add the contents of your Unity project folder to your repo and then commit and

“Wait a moment, you’re using Homebrew?”, you say Dear Reader? “If you are using Homebrew, shouldn’t we use the copy of the Apache that comes with Homebrew?”, you say?

It’s a viable alternative. Just like with PHP and other things, using a package manager like Homebrew to install the web server in user space means that you can keep up a lot more rapidly with upstream changes in Apache. Down side is you have to undo some things in the system and remember to confirm and redo these things when you update macOS.

Let’s go about it… we need to turn off the version of Apache included in the operating system:

sudo apachectl stop
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist 2>/dev/null

This turns off the server and unloads the system install of Apache from the list of services loaded at system startup.

Now we get things up and running with Homebrew:

brew install httpd
brew services start httpd

One more configuration adjustment: to keep things somewhat clean, Homebrew’s Apache installer defaults to run on port 8080 rather than port 80. This avoids conflicts issues between the system install of Apache and the Homebrew version. But we want the Homebrew version to server pages on the default port.

How to fix this, edit /opt/homebrew/etc/httpd/httpd.conf to switch the listen port to port 80. Use your favorite edit to find the Listen line in the file and make certain it looks like this:

Listen 8080

Now restart the server using brew services restart httpd.

An opinion

There is a common thread among the different blogs telling you how to do this that recommends you reset the server root to the Sites folder in your home folder. This is not something I recommend you to do as I believe you need to have a separation between production and development code. Feel free to reconfigure Apache in this manner as you wish but I’ll leave figuring how to do this to be an exercise for the reader.

Do go back and apply the changes I introduced in Part 1 of this series to get your home folder configured. All you need to do is adjust the files names to use the configuration files in your Homebrew install.

Apple recently made the decision to remove PHP from the OS image.   That’s a good call as the version included with the OS quickly gets out of date.   So, it’s up to us as software developers to manage the install and update of the development tool

A Quick Aside

Time to express an opinion: I am not a PHP fan. It’s a kludge of a language built on top of a kludge of web application architecture. But enough back-end stuff remains built on that architecture that one has to understand it and sometimes support it.

Back to our regular programming

For macOS, the simplest way to manage installing and configurating PHP is to use a package manager like Home-brew. It’s a one line install command:

/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”

Worth noting that is a lot of gooey, cruchy open-source goodness in the Homebrew repository.

At this point, you can install PHP:

brew install php

This will get you PHP8. If you need earlier versions, then you will want to use one of the specific version casks in Brew.

And now things get macOS ugly

We want to configure our Apache install to use PHP. H

Time to hack! Configuring Apache

Things begin by adjusting our Apache configuration to load PHP. Edit the Apache httpd.conf configuration file:

Sudo vi /etc/apache2/httpd.conf

Add the following:

LoadModule php_module /opt/homebrew/opt/php/lib/httpd/modules/libphp.so
<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

Confirm that the DirectoryIndex entry includes “index.php”:

DirectoryIndex index.php index.html

Now we code-sign

Here is where Apple tightening up security in macOS 12 bits us in the posterior: Homebrew’s stuff isn’t code-signed. Means that Apache will puke upon us when it tries to load the PHP module.

We have to manually sign the package. This requires some finagling with keychains using the Keychain Access utility and the Xcode command-line tools.

Here things get “interesting”. We need to adjust macOS to allow us to self-sign certificates. In other words, we get to be our own “Certificate Authority”.

Launch the macOS Keychain Access utility:

Now goto Keychain Assistant>Certificate Assistant>Create A Certificate Authority

. You should see something that looks like this:

Do the following:

1. Adjust the name as needed.
2. Select “Code Signing” from the “User Certificate” dropdown.
3. Turn on the “Let me override defaults” checkbox
4. Enter your e-mail at the appropriate location
5. Select “Continue“
6. Accept defaults for Certificate Information
7. Enter appropriate certificate information and select “Continue”
8. Accept defaults for the Key Pair information for both certificate and users
9. Do the same for extensions
10. Turn on the “Extended Key Usage Extension for This CA” option
11. Select the “Code Signing” checkbox that appears
12. Accept defaults until you get to the create screen
13. Turn on “On this machine, trust certificates signed by this CA“
14. Select “Create”
15. Close the “Certificate Assistant“

Sign the PHP module using the Xcode command-line code signing tool (replacing ”AWL“ as required):

codesign –sign ”AWL“ –force –keychain ~/Library/Keychains/login.keychain-db /opt/homebrew/opt/php/lib/httpd/modules/libphp.so

Now again edit the Apache httpd.conf file and adjust the entry for PHP as below (again, replacing ”AWL“ with what you used in the certificate):

LoadModule php_module /opt/homebrew/opt/php/lib/httpd/modules/libphp.so ”AWL"

Now restart Apache and you should be ready to rock and roll:

sudo apachectl -k restart

Selah.

A good chunk of what we need do web development exists in macOS 12.1 (Monterey) without having to resort to add-ons like the XAMPP stack. I have enough of my students asking me how to do this that I thought I would consolidate my notes and put them up on the web so I can just point them at that reference. This is going to pull from multiple sources and I’ll try to acknowledge every one that I can. Let me know if I missed one.

There are some things you will need to add.  Recent versions of macOS no longer include PHP as part of the operating system.  That’s actually a good thing as the tendency has been for the version included has tended to lag behind the current tip of development.  Here’s where you find yourself using a package manager like Homebrew.

First step: Configuring Apache

The OS includes the Apache web server.  It’s buried pretty deep into the system bits so you are going to having to apply some important skills:

• Understanding of working with the Terminal.app to run command-line programs to update configuration files and manage the web sever

,

• Know some of the internals of the Apache web server,
• And know how to open and save files in text editor like vi or nano.

This information is spread over the Internet but the bulk of the material is taken from the Apple tech support discussion forum at https://discussions.apple.com/docs/DOC-250004361

Start by editing the web server configuration file located at /etc/apache2/httpd.conf. Note that this requires admin permissions, so you will need to use sudo:

sudo vi /etc/apache2/httpd.conf

Look for the line in the file that enables the “Sites” folder for individual users (this is equivalent for macOS as public_html is for Linux). In recent versions of macOS, this is at line 184 in the file. Uncomment that line by removing the leading “#” comment indicator. It needs to read as follows:

Include /private/etc/apache2/extra/httpd-userdir.conf

Save and exit the editor.
 

This change tells the web server to look for an include configuration file that will define user folders in the web server. Edit that file:

sudo vi /etc/apaches2/extra/httpd-userdir.conf

Uncomment line 16 of that file so that it reads:

Include /private/etc/apache2/users/*.conf

Now you need to tell the web server that about your user folders. First step, look in the Users and Group preferences pane to get your short user name. Right click on your user name in the pref pane and select “Advanced Options”. The short user name can be found in the “Account Name” field. For discussion purposes, we’ll use my short name of “alewis”. Replace this with your own when you do this,.

Now let’s use your tex editor to create a configuration file for user folders:

sudo vi /etc/apache2/users/alewis.conf

Add the following content:

<Directory “/Users//Sites/”>
 AddLanguage en .en
 Options Indexes MultiViews FollowSymLinks ExecCGI
 AllowOverride None
 Require host localhost
</Directory>

You will need to add additional configuration items to this file if, for example, you want to enable PHP.

Then create the Sites folder in your home folder:

mkdir ~/Sites
echo “<html><body><h1> My site works</h1></body></html>” > ~/Sites/index.html.en

This creates the Sites folder and adds a minimal working example in the folder that we can test against shortly.

 

Now we have to do some shell voodoo. Apple has tightened up the security in macOS 12 to, by default, not allow other users access to a user’s folders,. The macOS installation of Apache is configured to run in a special hidden user account named “_www”. You need to setup an Access Control List (acl) that lets the web server have access to your folder:

chmod +a “_www allow execute” ~/Sites
 

And now we see if things work. With Apache, one should always use the web servers configtest command to make certain things are configured in a clean manner:

apachectl configtest
 

So… what’s apachectl? That’s a command line tool that one uses to control the web server (which is an Apache thing, and so works on any of the UNIX-based operating systems). If the config test returns ‘Syntax OK’, then you are ready to rock the web.

Now for macOS command-line magic… you need to tell macOS to start Apache at system startup:

sudo launchctl load -w /System/Library/LaunchDaemons org.apache.httpd.plist

If you want to get things running in the meantime, do a:

sudo apachectl graceful
 

At this point, navigate to http://localhost and http://localhost/~<your short user name> and see if you get the expected responses from the web server.

 
Reference: https://discussions.apple.com/docs/DOC-250004361

Next up: Getting PHP to work using Homebrew.