I've come across many articles about how to join a linux system to a Microsoft +Active Directory domain and they all work more or less with some tweaking. This is +my article, here describing my own processes for doing it, trying to explain each +bit as it comes.
+Part of a "Using Linux in a Windows Domain" group of posts.
+This article is for desktop Debian Linux - for setting up a PC so it can be used by a standard user of the PC.
About 5 years years ago, during a security sweep of a new "app" a
+client had started using, I discovered the hosting company's website
+had a robots.txt giving the paths of many pages on their website containing
+sensitive information.
+The whole thing is starting to snowball, so this is my statement.
A simple, portable, wrapper for the borg backup and restic utilities written in Nim.
+ +I've come across many articles about how to join a linux system to a Microsoft +Active Directory domain and they all work more or less with some tweaking. This is +my article, here describing my own processes for doing it, trying to explain each +bit as it comes.
+Part of a "Using Linux in a Windows Domain" group of posts.
+This article is for desktop Debian Linux - for setting up a PC so it can be used by a standard user of the PC.
About 5 years years ago, during a security sweep of a new "app" a
+client had started using, I discovered the hosting company's website
+had a robots.txt giving the paths of many pages on their website containing
+sensitive information.
+The whole thing is starting to snowball, so this is my statement.
SELECT haiku FROM
-tableHaikus WHERE LEFT(name,
-3) LIKE 'SQL';
-'Twas the morning after the fortieth
-And all through the house
-Not a creature was stirring
-Except the one making the coffee and Alkaseltzer
'Twas the morning after the morning after the fortieth
-And all through the house
-The creatures were starting to stir but generally still uncomfortable and underperforming
'Twas the morning after the morning after the morning after the fortieth
-And all through the house
-The creatures were stirring
-Even the mouse!
-It scurried up the staircase
-Squeaking the old well known phrase
-"Warning! Duration of hangover is proportionate to age!"
I've come across many articles about how to join a linux system to a Microsoft +Active Directory domain and they all work more or less with some tweaking. This is +my article, here describing my own processes for doing it, trying to explain each +bit as it comes.
+Part of a "Using Linux in a Windows Domain" group of posts.
+This article is for desktop Debian Linux - for setting up a PC so it can be used by a standard user of the PC.
I'll be running through the process I use for joining Debian Linux as a desktop to Active Directory. The steps should be fairly generic as they use packages available in most distributions, so adapt to your distro as required.
+This follows this article quite closely, with some changes.
I use neovim as an editor, aliases to vim. If you use another editor then replace vim with your editor i.e. nano in all cases.
First things first we need the right packages installed. This can be done by the following command:
+# apt install realmd sssd samba-common krb5-user adcli libsss-sudo sssd-tools libsasl2-modules-ldap packagekit libpam-mount
+sssd is a set of services and tools to manage the connection to the domain.pam handles general user authentication, and creation of mounts for network shares etc.realmd is a tool providing a simple way to discover and join domains.krb5 is a kerberos (authentication token) handler amongst other things.*-ldap, adcli are further tools use for domain administration.For the most part, when we say realm we mean your windows "domain name". We'll be using YOURDOMAIN.LOCAL as an example.
This is at its simplest a case of configuring basic krb5 and using realm join to actually join the domain.
Edit the krb5.conf file to set the default realm:
vim /etc/krb5.conf
+[libdefaults]
+default_realm = YOURDOMAIN.LOCAL # Should be in CAPS
+This will allow the krb5 client to identified the default realm. If you don't set this, then a realm will need to be specified with every kerberos request i.e. with kinit.
Realmd handles a massive amount of the work here. It used to be we had to manage a lot of this configuration ourselves, but realm now does a lot of it for us.
+You can discover information about the local domain by issuing the below command
+realm discover
+# or
+realm discover YOURDOMAIN.LOCAL
+If all looks good you can join it
+realm join --user={your administrator account} YOURDOMAIN.LOCAL
+And to check everything is OK
+realm list
+which should output something like
+yourdomain.local
+ type: kerberos
+ realm-name: YOURDOMAIN.LOCAL
+ domain-name: yourdomain.local
+ configured: kerberos-member
+ server-software: active-directory
+ client-software: sssd
+ required-package: sssd-tools
+ required-package: sssd
+ required-package: libnss-sss
+ required-package: libpam-sss
+ required-package: adcli
+ required-package: samba-common-bin
+ login-formats: %U@yourdomain.local
+ login-policy: allow-realm-logins
+Technically now the computer is joined to the domain and can authenticate. You can test with:
+kinit {domain user} # will authenticate as that user
+klist # to show the kerberos token validity
+kdestroy # deauthenticate as that user
+Or, of course, log out and back in as a domain user account.
+Open up your /etc/sssd/sssd.conf file and make a few tweaks
vim /etc/sssd/sssd.conf
+Most of this will already be completed in your file as realmd handled it. But check over +it anyway.
+[sssd]
+domains = yourdomain.local
+config_file_version = 2
+#services = nss, pam # commented out as these are socket units which are dynamically handled by systemd
+implicit_pac_responder = false # having set to true allegedly crashed some SSSD services. It's not essential.
+
+[domain/yourdomain.local]
+access_provider = ad
+id_provider = ad
+default_shell = /bin/bash
+krb5_store_password_if_offline = True
+cache_credentials = True
+krb5_realm = YOURDOMAIN.LOCAL
+krb5_ccachedir = /tmp
+krb5_ccname_template = FILE:%d/.krb5cc_%U
+full_name_format = %1$s
+realmd_tags = manages-system joined-with-adcli
+fallback_homedir = /home/%u@%d
+override_homedir = /home/%u@%d
+ad_domain = yourdomain.local
+use_fully_qualified_names = False
+ldap_id_mapping = True
+dydns_update = False
+
+# This next one was a real fix for me. I had some issues where a Group Policy was unreadable which crashed SSSD and prevented the user from logging in. Windows would silently ignore it, so never an issue. I like the fact it was highlighted to me, but is not ideal for a production machine where people need to log in. So we ignore unreadable GPOs.
+ad_gpo_ignore_unreadable = True
+Now update the PAM modules
+pam-auth-update
+and make sure to check [*] Create home directory on login is enabled.
+This will allow the system to validate the user again the domain, create the user's home directory and mount the user's network shares if set.
There's a chance you may want domain administrators to have sudo privileges. This can be done by adding the following line to /etc/sudoers
%domainadmins ALL=(ALL:ALL) ALL
+Having Samba configured also helps streamline connectivity to network shares.
+vim /etc/samba/smb.conf
+[global]
+ workgroup = yourdomain.local
+ realm = YOURDOMAIN.LOCAL
+ encrypt passwords = yes
+ client protection = encrypt
+There are a couple of further notes regarding GVFS and automatically mounting network shares in the article mentioned at the start, if you need those things in place I recommend checking through that article as well.
+We should be good to go. Let's run some tests.
+systemctl status
+# If the state is `degraded` you can see failed services by running this command
+systemctl list-units --failed
+I experienced some issues with SSSD failing due to unreadable GPOs mentioned above. I discovered SSSD crashed when trying to log in, and adding the SSSD option to ignore unreadable GPOs fixed it.
+Great! We're here. Now we can log in. +Either log in using the desktop login screen, or from a terminal enter:
+login {user name}
+to log in as that user. The home directory should be created during login and everything is ready to go.
+You can edit /etc/security/pam_mount.conf.xml to enable automatic mounting of shared folders at login. I have had mixed success with this, but I'll put it here anyway:
...prefilled content...
+<!-- this should go somewhere before the `<mkmountpoint ... >` block.
+ <volume
+ fstype="cifs"
+ sgrp="domain users"
+ server="yourserver.yourdomain.local"
+ path="share"
+ mountpoint="~/Network Drives/Share"
+ options="vers=3.0,sec=krb5i,cruid=%(USERUID),nodev,nosuid,noexec,rw"
+ />
+...prefilled content...
+SELECT haiku FROM
+tableHaikus WHERE LEFT(name,
+3) LIKE 'SQL';
+'Twas the morning after the fortieth
+And all through the house
+Not a creature was stirring
+Except the one making the coffee and Alkaseltzer
'Twas the morning after the morning after the fortieth
+And all through the house
+The creatures were starting to stir but generally still uncomfortable and underperforming
'Twas the morning after the morning after the morning after the fortieth
+And all through the house
+The creatures were stirring
+Even the mouse!
+It scurried up the staircase
+Squeaking the old well known phrase
+"Warning! Duration of hangover is proportionate to age!"
A website directory of all words that can be associated with their letters by not -sounding as their corresponding letter should do.
- -Simple single page website for a local accountancy business. -Has additional Vue.js implementation for news and exchange rates updates.
-A website directory of all words that can be associated with their letters by not +sounding as their corresponding letter should do.
+ +Simple single page website for a local accountancy business. +Has additional Vue.js implementation for news and exchange rates updates.
+ +About 5 years years ago, during a security sweep of a new "app" a
+client had started using, I discovered the hosting company's website
+had a robots.txt giving the paths of many pages on their website containing
+sensitive information.
+The whole thing is starting to snowball, so this is my statement.
For those that don't know me, I am an IT Professional, providing IT consultancy
+services to businesses around my local area of Devon, UK.
+I'm generally met with people who are happy to see me and trust my advice.
+Sometimes though that is not the case.
My client in question is a medium sized business in Devon. They employ
+approximately 70-100 staffmembers and have been in operation for over 60 years.
+They are a well known local business.
+Due to running a business this size, they naturally have outsourced some
+workloads to third-parties, specifically for this case, Health and Safety. They
+use the services of a Chartered Health and Safety Consultancy used by many other local businesses.
+For whatever reason, this H&S company had decided they could make "apps" for their
+clients to assist with entering H&S information amongst other things. Seems like a good idea, sure... but...
...These "apps" are not apps at all, they are in fact simple html index pages linking to various Jotform Forms, Google Sheets, etc. These html index pages are, for the most part, unauthenticated. This means anybody who knows the link to that page can access those forms and spreadsheets.
+As an example, if a random passer by on the internet was to go to a URL like https://thecompanyswebsite.com/someothercompany_portal.html they would be shown a list of links
+to various Health and Safety, Vehicle checks, holiday request forms, etc. All of which could be filled out without having to prove who they are.
OK, well maybe that doesn't look so bad. I mean, you'd have to know what the path of the page is (the someothercompany_portal.html bit) right? Well, yes, you would but that
+should never be a defense, ever. Even if a URL is difficult to guess (it's not), it does not mean it's impossible.
Yep, the portal URL may be difficult to guess (they're not), and if it was just that alone things may be OK.
+But...
+This Health and Safety Company also had to good sense not to let search engines index
+those portal pages. We don't want people's sensitive information being indexed by Google do we! Very Good.
Ah...
+The robots.txt looks something like this:
+
+There's about 510 lines like that.
+(You'll notice I have taken the care to pixelise out the paths. I appreciate
+pixalisation can be undone, but due to the fact you'd need to know the base URL
+for this to work, and if you had the base URL, you'd have the full robots.txt file
+anyway, I feel no further actions on my part need to be taken here.)
For the uninitiated, this robots.txt means that Google, Bing, DuckDuckGo, etc. will never try to index any content on any of those paths. However, this does absolutely nothing to stop +a badly behaved or malicious webcrawler/bot - In fact, this file will act as a lovely index to tell that webcrawler/bot exactly what pages you don't want it to see.
+Once again, on face value this just looks like someone will gain access to fill out forms and be a nuisance to the client business. However, on further investigation I +have discovered that some of these URLs contain plaintext information such as +names, email addresses, and telephone numbers of staff members. +In one particularely negligent case (which I only found today), names of parents and their children, including dates of birth, telephone numbers, email addresses of the parent plus their signatures and names, email addresses, telephones numbers and signatures of that child's sporting coach.
+That last case is extreme, but it's there, in plain sight, for anyone who happens +to find the right base URL and path of that particular case.
+In short, This. Is. Negligent.
+As I say, I first noticed this about 5 years ago, and immediately informed my client, and
+the Health and Safety company involved about it. I ended up being invited to a meeting with them all, and explained my findings and told them these pages should, at the very least, be behind some kind of authentication. From this they decided they would put in
+some authentication - but only as groups, i.e. office@clientem.ail, warehouse@clientem.ail etc. and not per user.
+Shocking. But at least it was something.
+Although... it isn't something... they only did it for my client, so perhaps they just
+wanted to shut me up. I don't know. But other paths remained without authentication.
+As time went on, new "apps" for my client appeared (once again without authentication) and so I warned my client about it again, and again, and again.
+Over the last week this has reared it's ugly head again. I once again provided warning to my client with reasons why.
+Humourously, my client forwarded my email to the Health and Safety company and their response to it went like the below:
We are in the process of modifying our own internal app and it is not normally
+publicly available, and has now been returned to password protection. To of
+found the URL for our own internal app would of taken more than bad acting,
+and probably more aligned with IT guru / junior hacker.
+"Not normally publicy available"?! Well, I've seen it publicly available for 5 years. +"To have found the URL for our own interal app ... hacker"!? Erm... no. I've proved already this can be found by anyone just looking around, no hacking required (well, no authentication required, so nothing to hack).
+OK, they haven't "accused" me of hacking, but it's close.
+I have not dignified that email with a response. But, I have reported the Health and Safety company to the ICO, providing links to the robots.txt page
+and the direct URL of the page containing parents and child information mentioned above. I'll let them deal with it from here.
+However, as the term "hacker" has been used, and I am very aware of court cases that have happened where a good samaritan trying to help protect people, has instead been victimised and made out to be the "malcious hacker"
+because people simply do not understand how the internet works.
So, in the fear something like that could happen to me, this article is my statement.
+I ask anyone actively involved in System Administration, Cyber Security, Data Protection, etc. to please get involved and share this article.
+If you like, you can join in on this Fediverse/Mastodon thread too.
Thank you for reading. I'm a bad writer and I don't write much, but I really needed to vent this, and put it somewhere for all to see.
+ +