Assigning permissions for Linux service account to add machines to AD

Create service account.

On the domain where the machines will be joined:
Open Active Directory Users and Computers. Enable Advanced Features on the “View” menu.

View the properties of the entire domain.

Select the Security tab, and select Advanced.

  • For this object and all descendant objects: Grant Create/Delete Computer objects
  • For descendant computer objects: Grant Reset password
  • For descendant computer objects: Read/write account restrictions
  • For descendant computer objects: Write all properties, Write all validated writes

Advertisements

A case study in wholistic computer system support

A case study in wholistic computer system support

A user emailed me directly asking for me to look at why his webapp isn’t starting. He was having trouble even looking at the logs with journalctl.

I had built the servers for the user, so he always tries to shortcut the support process of opening a ticket to the team queue, and just assigned it directly to me. I emailed the user back saying, “I’ve assigned it to the team queue for you.”

Well, within 5 minutes the level 1 support guy reached out to me saying he couldn’t find anything wrong. And yes, while nothing was wrong on the OS and filesystem level, the app still wasn’t starting.

The user, in the mean time, had remembered his service account that runs the app so he switched user to that and read the logs. It didn’t have permission to the parent directories, on the nfs mount point.

I set aside the tasks I had scheduled for this afternoon, and took a look. Aside from some setgid on the parent directory without g+rx, nothing looked amiss. The directory was owned by root.root which didn’t seem different from the other contents on the filesystem.

My manager approved just fixing the problem and we’ll sort out what caused it later. So the user and I ran chown -R appuser.appuser /mnt/appdir/subdir1 and then the application could get started again.

The investigation

I checked the sudoers history on the two application servers to see if any users ran sudo chown or sudo chmod even though it was locked down enough to prevent that. No activity with sudo looked related, so I then turned to the filesystem itself.

It is nfs, so it could be affected by other systems. After using mount | grep /mnt/appdir and showmount -e $SERVERNAME | grep $EXPORTNAME I had a list of the IP addresses that have access to this export from the nfs server.

I did a reverse dns lookup to get the hostnames because obviously those are easier to recognize than just a whole series of IP addresses. Immediately I recognized the systems as the other container proof of concept.

Before I even started checking bash history on those hosts, I reached out to the container research guy and he told that I think a reckless chown affected an nfs mount point that affected the app running on the original servers. He said yes, it was him, and he “was trying to set the permissions on the logs directory, but the container mounted the entire nfs.”

I thanked him for being honest, and reminded him that chown -R is serious business. He claimed that this is a further reason for having his own nfs mount point. Additionally, kubernetes has a known security flaw about the availability of an entire mount when mounting just a path of it to a container.

This second user made an additional rookie mistake last week when he changed network settings on a system over a network connection before confirming he had console access. Of course, it went offline and he had to get assistance fixing it.

Conclusion

Be very, very careful when you execute a chown -R! And you probably shouldn’t be doing that inside a container with any bind mounts…

Monitor owner and permissions changes

A user on the Fedora forum asked for assistance monitoring owner and permissions changes to files. I whipped up a general solution in shell.

It uses a compressed database to store the last run, and will show the changes of the requested attributes of each file.

Here’s some of the business logic.

   # not empty
   test -n "${CO_DEBUG}" && echo "Comparing ${CO_INPUT} to database ${CO_OUTPUT}"

   # learn current status
   scan_dir "${CO_INPUT}" > "${CO_TMPFILE}"

   # compare to database
   zcat "${CO_OUTPUT}" | diff -W300 --suppress-common-lines -y "-" "${CO_TMPFILE}"

   # replace database
   cat "${CO_TMPFILE}" | gzip > "${CO_OUTPUT}"

And the scan function is pretty simple. Just change what stat outputs if you want to monitor different file characteristics.

scan_dir() {
   # call: scan_dir "${CO_INPUT}"
   # output: listing of hash, owner+perm hash for each file
   local td="${1}"

   find "${td}" -exec stat -L -c '%u,%U,%g,%G,%a,%n' {} + 2>/dev/null | sort -t ',' -k6
}

The script stores its compressed databases in /var/cache/check-owners/, and it will make files named based on the base directory it scans, so /home would be db file /var/cache/check-owners/co.home.db.gz.

You could write a cron entry to call this once a day on a particular directory and email the output to you. A poor man’s AIDE, if you will.

Set word-read permissions on python libs

In an environment where the default umask is 0077 or similar, the pip utility for installing python libraries can set up new files that cannot be read by all users.

I dropped this script into my ~/bin dir so I can enforce other-read permissions easily on all the python libs. I wrote this script after hours and hours of troubleshooting python libs just to find out it’s an old-school permissions issue.


#!/bin/sh
# File: /usr/local/bin/set-readable-python-libs
worldreadpythonlibs_version="2019-05-31a"
for word in /usr/{local/,}lib{,64}/python* ;
do
find ${word} ! -perm -o+rX -exec chmod g+rX,o+rX {} + 2>/dev/null
done