XRDP Logon Hangs on Black Screen

I’m writing it down this time — after completing the steps to set up xrdp (installed, configured, running, firewall port open), we get prompted for credentials … good so far!

And then get stuck on a black screen. This is because the user we’re trying to log into is already logged into the machine. Log out locally, and the user is able to log into the remote desktop connection. Conversely, attempting to log in locally once the remote desktop connection is established just hangs on a black screen too.

Zoning, ORC 519.25, and 8%

ORC 519.25 says:

The board shall adopt a resolution if there is presented to it a petition, similar in all relevant aspects to that prescribed in section 519.12 of the Revised Code, signed by a number of qualified electors residing in the unincorporated area of such township included in the zoning plan equal to not less than eight per cent of the total vote cast for all candidates for governor in such area at the most recent general election at which a governor was elected, requesting that the question of whether or not the plan of zoning in effect in such township shall be repealed be submitted to the electors residing in the unincorporated area of the township included in the zoning plan at a special election to be held on the day of the next primary or general election. The resolution adopted by the board of township trustees to cause such question to be submitted to the electors shall be certified to the board of elections not later than ninety days prior to the day of election at which said question is to be voted upon. In the event a majority of the vote cast on such question in the township is in favor of repeal of zoning, then such regulations shall no longer be of any effect. Not more than one such election shall be held in any two calendar years.

Which made me wonder how many people, exactly, 8% would be. Well, the last election for Governor was 2018, so a quick trip to the Board of Elections site for the 2018 precinct result details shows

2016 Governor’s Race
Precinct Registered Voters Votes Cast
Hinckley A 1437 1009
Hinckley B 1253 867 Total Cast 4059
Hinckley C 1134 735 8% 324.72
Hinckley D 1213 803
Hinckley E 902 645

 

Since the number of signatories needs to be greater than or equal to 8%, that’s 325 people. Which … isn’t really an insurmountable obstacle in a township with just over 5,900 registered voters — about 5.5% of the registered voters.

Police Resignations

Scott came across a video where some cop in Florida rips into this lady who drive for about a mile after he put his lights on — along a dark, uninhabited road — to stop at what looked like a petrol station. It was odd because I had an uncle who worked in law enforcement and I distinctly remember him saying to get somewhere well lit and around people before pulling over. Put on your hazard lights, drive slower … but get somewhere in public. And visibility helps the cop too — they can see that the blob in your hand is just your purse.

The video had some text at the bottom that said the deputy involved had resigned … but that could mean he resigned before the department was able to investigate the incident, got a job elsewhere, and is out there right now hassling some other person who simply made the prudent decision to stop their car in a safer spot.

Which made me think about some of the Township meeting — when someone from the fire department or police department resigns? They don’t just say “hey, I’m not gonna be working after Friday” and that’s it. They submit a resignation. The resignation is then submitted at the Trustee meeting — and the Trustees vote to accept the resignation. It seems like we could better unsure officers are held accountable for their actions by not accepting resignations if there is any outstanding complaint against the individual tendering their resignation. Wait for the complaint to be resolved — maybe it was nothing and they can resign. Maybe it bears an investigation. But there’s no leaving to avoid accountability.

Cisco – Converting Access Point from Lightweight to Autonomous Firmware

I’ve seen a number of walkthroughs detailing how to convert an Aironet Wireless Access Point that’s using the lightweight firmware (the firmware which relies on something like a CAPWAP server to provide configuration so there’s not much in the way of local config options) to the autonomous firmware (one with local config & a management GUI). A few people encounter issues because downloading firmware requires a TACACS agreement — great if you’re a network engineer at a company, not great if you’ve bought a single access point somewhere.

While “google it and find someone who has posted the file … then verify the MD5 sum checks out” is an answer, a lot of the newer firmwares appear to have a major bug where any attempt to commit changes yields a 404 error. ap3g2-k9w7-tar.153-3.JF12.tar, ap3g2-k9w7-tar.153-3.JF15.tar, ap3g2-k9w7-tar.153-3.JPI4.tar — all very buggy.  While it may be possible to use the CLI to “copy ru star” and write the running config into the startup config … that’s going to be difficult to explain to someone else. Something else odd — the built-in Cisco account is a ‘read only’ user — this may be normal where the GUI shows it as read only but it’s actually got management permission?

What I’ve realized, in our attempt to convert into a fully functional autonomous firmware, is that the specific version referenced in one of the walkthroughs (ap3g2-k9w7-tar.153-3.JH.tar) is a deliberate selection — it’s a security update firmware release. Which means it’s available for download for anyone with a Cisco account that’s OK for encryption download (i.e. not residing in one of those countries to which American companies are not allowed to ‘export’ good encryption stuff) even if you don’t have a TACACS account.

Luckily, the JH iteration of the firmware doesn’t have the 404 error on committing changes. The Cisco account is still showing up as read-only, but we were able to make our own read-write user & implement changes.

Macrame Project – Hanging Plant Basket

I have eight spiral knot “arms” on the plant hangar — it’s starting to look like a sea critter!

The trick that I’ve found to macrame is managing the cords as you work. It’s rather difficult to make knots with four eight foot cords. Gathering the working cords into individual bundles (and, since I am doing square knots where two cords are being wrapped around a pair of cords … I gathered two of the cords into one bundle) makes the whole process quicker and easier.

The tie around the “active” cords then matches up with the string color on my knot diagram — which is great for remembering which of the two knots you just tied!

On Federated Identity Providers

The basic idea here is that you may want someone to be able to validate your users without actually having access to your passwords or directory data. As a counter-example, a company I work with has their payroll “stuff” outsourced. Doing so required a B2B VPN that allowed the hosting company to access an internal LDAP directory. I set up an access control list for their connection so they could only authenticate users. Someone at the hosting company couldn’t download all of the e-mail addresses or phone numbers. Even so, a sufficiently motivated employee of the third-party company could get the logon and password for anyone who used their server – if it’s my code, adding the equivalent of ‘fileHandle.write(f”u:{username} p:{password}”)’ would write a log file with every cred used on the site.

Don’t contract with dodgy companies that are going to drop your user creds out to a file and do malicious stuff is a good start, but I would concede that “avoid dodgy companies” isn’t a great security paradigm.  Someone came up with this “federated identity” methodology — instead of you asking the user for their ID and password, you get a URL to redirect not-yet-logged-on users over to someone trusted to handle passwords. This is the “identify provider”, or IDP.

I access your website (called the ‘service provider’, or SP), and you see I don’t have any sort of auth cookie to get me logged in. You forward my browser, along with some header info, over to IdentityProviderSite. IdentityProviderSite says to the end user “hey, what is your username and password”, checks that what is entered, maybe does the MFA “really, prove it” thing, and then redirects the browser back to the originating website. It includes some header stuff that says “Hi, I am IdentityProviderSite and I used my trusted private key to sign this message. I promise that the person associated with this connection is really Lisa. And here’s her important info (could just be username, could be first name, last name, email address, etc) that you can also trust is right.” No idea why, but the info about the person is called an “assertion” — so you’ll see talk about mapping assertions (which is basically telling my application that the thing it calls “logonID” is going to be called “userID” or “uid” or whatever in the data coming from IdentityProviderSite). Voila, I’m now on your website and logged in even though my password never transited your system. All you ever got was a promise that the person on this connection is really Lisa.

To accomplish this, there is a ‘trust’ between an application & an identity provider — if you tried to send a web user to IdentityProviderSite without establishing such a trust, it would say “yeah, I’m not validating users for you — I have no idea who you are”. And, similarly, a web app isn’t going to just trust any random source to say “really, I promise this is Lisa”. So we go into the web application and say “I really, really want to trust IdentityProviderSite when it tells me a user’s ID” and then go into IdentityProviderSite and say “I want WebApp to be able to ask to validate users”. And there’s some crypto stuff because IdentityProviderSite signs it’s “I promise this is Lisa” message & we don’t want someone to be able to edit that to say “I promise this is Fred”.

Why, oh why, is “where to send the authenticated person back to continue on their merry way” called an Assertion Consumer Service? The “service provider” is supposed to “consume” the identity … so it’s the URL of the “assertion consumer” (i.e. the code in the application that has some clue what to do with the “I promise this is Lisa” blob of data that they call an assertion).

Does this make any sense for third-party companies that we really shouldn’t trust? Companies that aren’t located on our internal network to access our directories directly? Absolutely! Does this make any sense for our internal stuff? Stuff with direct, encrypted access to the AD directory? Eh … it goes well with the “trust no one” security principal. And points for consistency — every app’s logon will look the same. But it’s a lot of overhead / Internet traffic / complexity, too.

The basic process flow when a user attempts to use a site is:

  1. A client attempts to access some web resource to which they are not already authenticated
  2. The end web application redirects the client to the Identity Provider.
  3. The Identity Provider authenticates the user.
  4. The Identity Provider redirects the client to the Assertion Consumer Service (ACS) on the web resource by sending a SAML response over HTTP POST.
  5. The web server processes the SAML response.
  6. The client is redirected to the actual web application URL
  7. The web server authorizes the user to access the requested web resource.
  8. The application server sends the HTTP response back to client.