Running Kace SMA (K1000) version 11.0.273. Wanted to run it behind a reverse proxy so it wasn’t directly exposed to the internet. Generally speaking, you really don’t want things like webservers directly exposed to the internet for obvious reasons, but KACE has been really adamant about security and running it in a DMZ and it hasn’t had any known intrusions to date.

In any case, I decided to move it out of the DMZ and run HAProxy in its place. I have my outside-of-this-documents-scope reasons. However, KACE SMA 10.x didn’t play nicely with reverse proxies even with legit SSL’s installed (you can read about konea certificates vs web ones on the kace support pages).

Upgraded to version 11 and from there it splits into two – konea certificates are unpublished but necessary, and then our web certificates for all other traffic. And yes, all traffic does terminate to port 443, but the konea side changes to a new port.

global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
        stats timeout 30s
        user haproxy
        group haproxy
        daemon
        lua-load        /etc/haproxy/acme-http01-webroot.lua

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE>
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
        log     global
        mode    tcp
        option  tcplog
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

frontend http-in
        bind *:80
        acl url_acme_http01 path_beg /.well-known/acme-challenge/
        http-request use-service lua.acme-http01 if METH_GET url_acme_http01


frontend sma
#       bind *:443 ssl crt /etc/letsencrypt/live/pem/
        bind *:443
        tcp-request inspect-delay 5s
#       tcp-request content capture req.ssl_sni len 25
        tcp-request content accept if { req_ssl_hello_type 1 }


        use_backend sma_agent if { req_ssl_sni konea }
        use_backend sma_webui if { req_ssl_sni mykacesite.domain.tld }
        default_backend sma_webui

backend sma_webui
        server sma_apache 10.130.20.6:443

backend sma_agent
        server sma_koneas 10.130.20.6:52230

I should point out that I also am utilizing letsencrypt for the web portion, however, by switching to tcp mode instead of http it bypasses that requirement. TCP mode is REQUIRED for the konea portion to actually function.

Taking over the IT department when the previous IT regime had zero plans on how to integrate the series of businesses they had taken over in the past several years makes for some fun times. I have 4 different godaddy accounts, a couple DH accounts, and even one from a German company I had never heard of. And I had to fight, beg, talk, email, reverse engineer, and guess on several logins. Something something “no documentation”.

That being said, I’ve also had the responsibility of migrating and managing some of our wordpress sites and was SOL when it came to logins. Luckily GD, DH, and even the German cpanel host company all allowed for some sort of mysql access – whether that was shell access or phpmyadmin – so I could “easily” reset the credentials.

On Dreamhost using SSH:
mysql -h MYSQL.DOMAINNAME.TLD -u MYDBUSERPASSWORDFROMTHEPANEL -p
Enter your DB User password
show databases;
use DATABASENAMEHERE;
show tables;
Look for one with “users” at the end (eg wp_users)
List the Users Table along with the ID you’ll need later (First Column)
select id, user_login, user_pass from NAMEOFUSERTABLE;
update NAMEOFUSERTABLE set user_pass = MD5('YOURNEWPASSWORDHERE') where ID = NUMBERFOUNDABOVE

Through PHPMYADMIN
Open PHPMyAdmin and click on the WP database
Find the “Users” table (eg wp_users)
Click on Browse
Click on edit by the user for which you desire to change the password
Where it says “user_pass” change the function drop down to MD5 and then type in a plain text password.
Hit save/submit