@dafyre said in What do you use as an identity provider?:
We use WSO2's Identity Server here
It seems popular and so does Redhat's Keycloak.
I thought you had to have paid support to get patches and that it's cost prohibitive for small companies ($20K/year).
@scottalanmiller said in What do you use as an identity provider?:
@Pete-S said in What do you use as an identity provider?:
You mean if you paid for M365 then you're already using Azure AD as your identity provider in which case JumpCloud serves no purpose?
For one thing, Azure AD is lacking connectors for normal things like Linux desktops. Doesn't even WORK in our environment or most of our customers, almost none. At most it works for SOME workloads.
There is another factor as well, which favors an independent identity provider and authentication. When you have everything in one place, you give too much power over your business to a single company. If you have a problem with Microsoft (or Google) all other services will be useless if you tied everything to Azure AD (or Google Identity Services).
Also changing "Office" apps from Microsoft to Google or to Zoho or whatever you might fancy will have far reaching implications. So less freedom to pick whatever is best for your company.
@Dashrender said in What do you use as an identity provider?:
Have no type of SSO.
All systems are separate.
I think that is pretty common too.
A lot of SaaS apps also requires that you have signed up for the enterprise tier to be able to do SSO. From what I've seen legacy on-prem software usually needs AD and then from there you can sync to an identity provider.
@jt1001001 said in What do you use as an identity provider?:
@Pete-S Old job we used Azuer AD exclusively because we were already in that space; no need for a'Third party" provider. We did review Okta as it integrated with on premise AD, and liked it but why spend extra $$ since we had to get E5 licenses already for other reasons. If you have a lower license teir Okta may make sense as its I think US$6/user/month if I remember correctly.
Haven't started new job yet so I don't know what system they're using.
I think that scenario is pretty common. Did you authenticated other SaaS apps with Azure AD as well?
@Dashrender said in What do you use as an identity provider?:
@Pete-S said in What do you use as an identity provider?:
I don't know if Azure AD would make sense as a standalone service, without users being on M365 or having Windows infrastructure in general.
I'll agree with you there - which is why I said - IF you have M365 or Google Workspace already....
If you don't, yeah, I likely wouldn't look to them as a basis for an identity provider, but if you already have them.... As I've done zero research - I have no clue what OKTA or DUO, etc bring to the table.
What do you guys do at your place?
@Dashrender said in What do you use as an identity provider?:
@Pete-S said in What do you use as an identity provider?:
@VoIP_n00b said in What do you use as an identity provider?:
JumpCloud’s SSO goes beyond application access to provide a single identity that can access any IT resource, from applications to devices, networks and more. Backed by a robust Directory Platform, you can onboard, offboard, and manage the lifecycle of every user with a single set of credentials. With one identity per user, you can easily provision and deprovision user access to devices (MacOS, Windows, and Linux), on-premise applications, networks and VPN, and servers from a single, secure console.
Thanks. Are you using it as well?
Have you integrated JumpCloud with M365 or Google Workspace or whatever you might use?
If you have azure AD or Google Workspace, why bother with Jumpcloud?
You mean if you paid for M365 then you're already using Azure AD as your identity provider in which case JumpCloud serves no purpose?
I'm not 100% clear what capabilities each system have but I would guess that dedicated identity platforms such as JumpCloud, Okta, Onelogin etc are more mature, sophisticated and has more features.
I don't know if Azure AD would make sense as a standalone service, without users being on M365 or having Windows infrastructure in general.
@VoIP_n00b said in What do you use as an identity provider?:
JumpCloud’s SSO goes beyond application access to provide a single identity that can access any IT resource, from applications to devices, networks and more. Backed by a robust Directory Platform, you can onboard, offboard, and manage the lifecycle of every user with a single set of credentials. With one identity per user, you can easily provision and deprovision user access to devices (MacOS, Windows, and Linux), on-premise applications, networks and VPN, and servers from a single, secure console.
Thanks. Are you using it as well?
Have you integrated JumpCloud with M365 or Google Workspace or whatever you might use?
What do you use as an identity provider for all different logins the users have?
I mean if the users have 20 different web apps, they don't really want to login with different usernames, passwords, OTP etc for every one of them. But perhaps that is what most people do?
If you use an identity provider are users using that to logging on their workstation as well? Also VPNs perhaps if that is in use?
I'm trying to figure out what options are commonly deployed, if any.
@JaredBusch said in FreePBX Contact Manager to Yealink Address Book:
@vgvelukashvili said in FreePBX Contact Manager to Yealink Address Book:
Good day,
Is it possible to add the option in to the script to grab the Contact Images as well? Would be great
How does that get put into a yealink contact xml?
Maybe this could help: http://forum.yealink.com/forum/archive/index.php?thread-4123.html
@jaredbusch said in Password Managers:
@pete-s said in Password Managers:
If you use an online password manager or anything not open source you still have to trust them.
You still have to simply trust open source.
Can you read all the code and know that their encryption is valid? That there are no exploitable bugs?
True, but it a lot easier to put more trust in something that is completely transparent and can be verified by independent sources.
@jaredbusch said in jira + nginx - can't login via https:
@pete-s said in jira + nginx - can't login via https:
You're using https but you don't have any information for proxying tcp 443 assigned in the nginx config.
It is, you even quoted it
My bad. I thought his internal server running jira was setup to use https (self-signed certificate) on port 8443 (with redirect on 8080).
@emoxam said in jira + nginx - can't login via https:
I'm trying to setup jira server via nginx proxy.
made a A dns record for it, made an port forwarding to NGINX (with certbot installed),
at nginx i got this jira.blabla.com. conf config[server { server_name jira.blabla.com; location / { proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://172.16.1.19:8080; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/jira.blabla.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/jira.blabla.com/privkey.pem; # managed by Certbot ssl_protocols TLSv1 TLSv1.1 TLSv1.2; } server { listen 80; server_name jira.blabla.com; return 301 https://$server_name$request_uri;]/opt/atlassian/jira/conf/server.xml
<Connector port="8080" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false" maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443" acceptCount="100" disableUploadTimeout="true" bindOnInit="false" secure="true" scheme="https" proxyName="jira.blabla.com" proxyPort="443"/>old one is commented
<!-- <Connector port="8080" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false" maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443" acceptCount="100" disableUploadTimeout="true" bindOnInit="false"/> -->i opening https://jira.blabla.com
and i can't login with no error
with the sane credentials i can login at http://jira.blabla.lan:8080/
You're using https but you don't have any information for proxying tcp 443 assigned in the nginx config.
@obsolesce said in Password Managers:
Last I seen
So you have validated their source code? Or did you read it from their webpage?
Just to be clear, I'm not saying Lastpass doesn't do what they say they do. I only state that you don't know.
I'm sure their intensions are good but software is not perfect. That why there are plenty of vulnerabilities and bugs in everything.
@scottalanmiller said in Password Managers:
You are asking them to store the ENCRYPTED data of your passwords. You don't have to trust anyone. You should still use a vendor you trust, of course, but there's no need for trust. That's the point.
If you use an online password manager or anything not open source you still have to trust them.
Because you don't know what they do with your master password, encryption keys and other things.
Lastpass for example have passed security audits but still have had multiple breaches. There also have been examples of malicious browser extensions grabbing passwords.
As with anything, "safe" doesn't really mean safe, it means a little bit safe. And often safe enough - depending on what you are protecting.
@eddiejennings said in Password Managers:
@notverypunny said in Password Managers:
I've gotten too used to KeePass over the years and have a hard time getting used to or trusting anything else
I have my own KeePass specifically for stuff on my work laptop.
We use KeePass as well for our own passwords. Since it's file based it can be securely stored anywhere and replicated. You can open the password file on any device with KeePass installed. So it's hard for us to lock ourselves out completely.
We also use Zoho Vault but for different kind of passwords. I haven't used it much though.
@dashrender said in Locking down vendors:
@pete-s said in Locking down vendors:
Yes, on a VLAN for each network.
If it's highly sensitive or for compliance, separate switches are needed for these networks to avoid vlan hopping or misconfigured switches that allow access to restricted network assets. Normally it's not needed though.
A separate firewall also sounds like it's not needed unless you have some serious security concerns.
ZeroTier doesn't sound like the best tool for the job though.
Something like OpenVPN with certificates and perhaps with added OTP is much better suited.
You want to give access to people on a time-limited basis. Certificates have expiration so that is great. OTP ensures that knowing passwords and having a certificate is not enough.
When clients log in they are put in a specific IP and you control their network access to their VLANs through your firewall's rules..
That way you have something that can grow. VPN provides access and security is handled in your firewall.
If you want something hosted (like ZeroTier is), I'd look into Cloudflare Access. They use wireguard for the VPN access and their network controls access.
What don't you like about ZeroTier? I do like the added security of the OTP, though I'm not sure if I need to go that far. ZT would be locked down to the single device. No clue if an install could be moved from one install of Windows to another...
OTP is best practice today. Well, it's been that for a long time.
We have VPN vendor access to several companies and they all use MFA with OTP. We're also required to sign contracts for the remote access.
@dashrender said in Locking down vendors:
@pete-s said in Locking down vendors:
@dashrender said in Locking down vendors:
My plan is to use ZeroTier for remote access. One advantage of that is I can easily limit the number of stations the vendor can use to access our systems, the PITA part is if they need to use a tech who normally doesn't have access, the vendor now has to reach out to get them setup - which is a PITA for a temp type access.
If you don't want your login, passwords and what not distributed among many people, it's important thing is that give access to a person at a vendor and not generic access to a company.
We deal with this a lot as a vendor and access credentials is always given to a single person and not the company. If someone else needs access that person also need their own credentials.
uh - what? that one guy can do anything he wants once he leaves your presence. He could hand the password to anyone. You hope they don't of course.
Sure, but the new guys needs the same OTP (the same [email protected] and OTP device) and he needs the username, the password and the certificate.
I don't have a guide but have researched it and the basic building blocks are your linux OS of choice and postfix.
So if you search for smtp relay and postfix you will find a lot of info.
@fredtx said in Wsus for remote vpn and on-premise users:
@dashrender said in Wsus for remote vpn and on-premise users:
What is the goal here? to keep the servers up to date? Do you really want WSUS to update your servers 'whenever'? Most people don't, could lead to an unexpected reboot in the middle of the day.
Of course I would not want the servers to reboot in the middle of the day. I would have to discuss with management on maintenance windows of downtime, since this is a manufacture business where some sites run 24/7.
The goal is to improve and simplify how patching is handled for both servers and workstations. Currently there is no kind of process in place.
We do some of that and the most mission critical servers are handled manually. Patched, rebooted and verified that everything works.
Basically there are different categories of servers and workstation and each category is handled differently depending on how mission critical it is.
@dashrender said in Locking down vendors:
My plan is to use ZeroTier for remote access. One advantage of that is I can easily limit the number of stations the vendor can use to access our systems, the PITA part is if they need to use a tech who normally doesn't have access, the vendor now has to reach out to get them setup - which is a PITA for a temp type access.
If you don't want your login, passwords and what not distributed among many people, it's important thing is that give access to a person at a vendor and not generic access to a company.
We deal with this a lot as a vendor and access credentials is always given to a single person and not the company. If someone else needs access that person also need their own credentials.