@stacksofplates said in sssd and user ID mapping:

@Pete-S said in sssd and user ID mapping:

@Semicolon said in sssd and user ID mapping:

@Pete-S If it is an issue, its trival enough to prevent public key authentication for users or groups of users, even groups of AD users.

Sure, but the problem for developers and admins is that they usually need their keys. That's why I don't think ad/ldap integration with ssh users really works in that use case.

The other solution, which is what I think is more suitable for developers and admins, is to use your SSO/AD solution with MFA to pickup a short-lived ssh certificate. Then you use the ssh certificate to actually access things.
Many companies with huge infrastructures use this method because it's very scalable.

We forced kerberos for SSH auth after wen enabled AD integration. SSH works like keys then but you don't use the keys.

Never used it but it seems to be a good solution if you want AD integration.

I noticed that gitlab also supports kerberos for pushing and pulling. I assume github does too. That's very convenient.

@travisdh1 said in Apple 2FA:

@Dashrender said in Apple 2FA:

@JaredBusch said in Apple 2FA:

@black3dynamite said in Apple 2FA:

Allow approval from notifications. But it's disabled if you enable Authy protection PIN.

@Dashrender read the entire fucking line....

The app supports it unless you proctect it in the first place. which you should..

It has nothing to do with the service.

I don't recall such a conversation - I'm specifically talking about push notifications - I was unaware that third parties were able to register for and receive push notifications like Google and MS (and frankly Apple) provide their MFA apps.

This is a whole other topic again.

When do you think apps stopped being able to do push notifications? That's all it is.

huh? The MS authenticator registers itself for push notifications from MS, GA does from Google - are you saying you can do that with Authy for google and microsoft services?

I completely understand that I can add TOTP to Authy for MS and Google, but I quoted and am specifically asking about push notifications from those via Authy.

My google foo is finding nothing but people bitching about how authy does NOT support push, but does support TOTP.

Now all that said - I see that Authy has created One Touch - and that One Touch as an API that allows push notifications, but I can't find anywhere that says that Google/MS have enabled that feature.

@Pete-S said in Digital Signage - Display HTML5 Page That Requires a Login:

You could probably make a script with curl that will login to smartsheet every 5 minutes or whatever, downloads the html5 dashboard page and save it somewhere. Then your media player can access the saved data.

As @Romo said, login details are not sent in the URL.

Yeah. I was thinking it was a long shot. I have been trying to figure out ways to create a local dashboard or similar to what you were saying that does that, or pulls info via an API and then the signage player connects to that, sans login.

Got it. I was using the account id with an application key.

A more careful reading of the above linked page shows that:

0_1542076748186_e6061550-5167-4def-b9b5-5b89e859f408-image.png

So that was the disconnect.

Application Key requires Application ID. Account ID requires Master Application Key.

When the examples clearly stated ACCOUNT_ID and APPLICATION_KEY

0_1542076683650_e8a7c2f9-0a93-4c35-b429-0bf24767fe33-image.png

Cheap meaning low cost, of course.

@aaronstuder said in How to setup Nginx TLS certificate based Authentication (VPN alternative):

@emad-r 3650 🙂

One of the main reasons that normal certs cannot be bought with forever expiration is because then people would be less apt to update them as ciphers are broken.

Look at how many people still use(d) SSLv1 SHA1, etc., long after they were proven broken.

@jaredbusch said in Nginx Certificate Authentication issue:

@emad-r said in Nginx Certificate Authentication issue:

@jaredbusch said in Nginx Certificate Authentication issue:

ls -laZ /etc/pki/nginx/ca.crt

-rw-r--r-- root root ?

i specified -laZ intentionally to show the SELinux context also.

I don't have your directory setup, but this is what my /etc/pki/tls/certs looks like

drwxr-xr-x. root root system_u:object_r:cert_t:s0 . drwxr-xr-x. root root system_u:object_r:cert_t:s0 .. lrwxrwxrwx. root root system_u:object_r:cert_t:s0 ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem lrwxrwxrwx. root root system_u:object_r:cert_t:s0 ca-bundle.trust.crt -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt -rw-r--r--. root root unconfined_u:object_r:cert_t:s0 dhparam.pem -rwxr-xr-x. root root system_u:object_r:bin_t:s0 make-dummy-cert -rw-r--r--. root root system_u:object_r:cert_t:s0 Makefile -rwxr-xr-x. root root system_u:object_r:cert_t:s0 renew-dummy-cert

Thanks this pointed me in the right direction, a useful guide coming soon

@JaredBusch how did you setup your NIC for the workstation that had to remote into the AD via ZeroTier? I'm still trying to figure out exactly what was statically assigned as your post wasn't too clear for me (this is new to me).

@jospoortvliet said:

with regards to the VHDX, we decided to remove the VHDX for now, we can't built it due to a server problem... It'll be back but that can take a while. Sorry! Hope the other formats suffice.

Thanks for your feedback !

I think that that was for the other thread.

@travisdh1 said in UNIX: The /etc/shadow File in Depth:

@stacksofplates said in UNIX: The /etc/shadow File in Depth:

@scottalanmiller said in UNIX: The /etc/shadow File in Depth:

@travisdh1 said in UNIX: The /etc/shadow File in Depth:

Man, I did just sneak in after /etc/shadow became standard in the 90s.

I was just before it.

I was way after.

Is this where I yell "Get off my lawn you young whippersnapper!"?

It's certainly where I do.

It's always best practice to disable root login over SSH, especially from the Internet; use su or sudo for root access. Another good practice is to disable password-based authentication; only use keys with a passphrase. The setup you're doing here is useful for allowing scripted/automated connections between machines (e.g. for backups, scheduled tasks, etc) but they should be accounts with limited access, not root. You should be creating layers that make it difficult for someone to gain access to your systems; root keys with no passphrase means you're solely relying on that one strong password (which is one keylogger away from being defeated.)