If you're working within Excel, then Python is not what you're looking for.
If you're manipulating files, preferably csv files, then Python is your friend.
I bet you there's a nice module that makes it easy to work with csv files, and then saving into a csv file is pretty easy.
I was looking at multiOTP, which looks like it would be a good free way of implementing 2-step authentication for RDP
https://github.com/multiOTP/multiotp/wiki
http://servilon.com/two-factor-authentication/
But I would imagine that in SMB, people would find it annoying to have to get a code every time.
And then I found this post that makes me think you could use the 2-step authentication in order to whitelist IPs
Maybe I'll try to lab it sometime
Haha, I just posted a long post on a forum before watching this video, and I literally thought, "I think I have a lot of good points in this post, but what are the chances someone is going to read this post at all?"
Often when reading a thread that's come up from a Google search, I will just skip over a WoT and only go back if later posts either didn't fill in the context, or indicate that there was good information in it.
@scottalanmiller said in The Myth of RDP Insecurity:
@flaxking said in The Myth of RDP Insecurity:
@scottalanmiller said in The Myth of RDP Insecurity:
@flaxking said in The Myth of RDP Insecurity:
Requiring long passwords might be a way to help mitigate this, but practically speaking, a lot of IT pros would get major push back from management if this was implemented.
Right, but it is very important to understand then that the problem here is management determining that security is not to be implemented, not a problem with RDP.
If this policy is the case, then a VPN will not resolve it.
Right, agreed. Your main point in this thread is that RDP isn't the vulnerability. But practically speaking, you have to mitigate the risks surrounding it, and that's what I think a how-to would be good for, though it might need several different scenarios.
You do, but I think the point is that you can't mitigate them with a VPN, which is the normal assumption. RDP isn't really vulnerable, it's not RDP risks that need to be mitigated. And RPD contains an extremely secure VPN, so a VPN can't be the solution. There can be risks, but they are from other tech or organizational risks and mitigations are to those risks, not to RDP risks. Those risks remains, such as weak passwords, whether RDP is used or not.
I'm not a big VPN fan, but they often can provide additional security that plain RDP does not. Client certificate authentication for example.
However, I agree that just wrapping RDP with a just password-secured VPN isn't providing additional value.
@scottalanmiller said in The Myth of RDP Insecurity:
@flaxking said in The Myth of RDP Insecurity:
Requiring long passwords might be a way to help mitigate this, but practically speaking, a lot of IT pros would get major push back from management if this was implemented.
Right, but it is very important to understand then that the problem here is management determining that security is not to be implemented, not a problem with RDP.
If this policy is the case, then a VPN will not resolve it.
Right, agreed. Your main point in this thread is that RDP isn't the vulnerability. But practically speaking, you have to mitigate the risks surrounding it, and that's what I think a how-to would be good for, though it might need several different scenarios.
@dafyre said in Dipping Toes Into Programming:
I keep shooting myself in the foot trying to use PowerShell syntax for stuff.
I feel like that problem just gets worse before it gets better (does it ever get better?)
@scottalanmiller said in The Myth of RDP Insecurity:
@flaxking said in The Myth of RDP Insecurity:
I would love to see a practical how-to on securely setting up external access with minimal resources.
If you only need to expose a single RDP "server" to the outside, the necessary settings for a normal environment are trivial. Setup up RDP as normal, use proper password and account security, add singular port mapping from network firewall to RDP "server". That's it.
For more security, of course IP locking and such is not hard, but might not be warranted.
I believe more security is required in order to mitigate the risks caused by things that are difficult to control.
For example, user created passwords. I'd guess that 80% of user passwords that user's aren't reusing from somewhere else contain the business name. Requiring long passwords might be a way to help mitigate this, but practically speaking, a lot of IT pros would get major push back from management if this was implemented. I'm not saying management would be right to push back since they're not providing the budget for a more secure solution, but that's the reality of many SMB. In their eyes, availability tanks.
In that situation I would not be comfortable with putting forth direct RDP as an option.
@scottalanmiller said in The Myth of RDP Insecurity:
@flaxking said in The Myth of RDP Insecurity:
One thing to think about is that this might change who has access to create accounts that can access the system externally. i.e. now every local admin has that power, when with a VPN that power might be a bit more naturally contained.
Not really. Local admins can't open the outside firewall ports. And who is creating local admins? Any anyone that can create an RDP session because of their admin rights, can also create a VPN through those same rights.
In a basic RDP setup, the ports are already open and mapped. The concern wouldn't be someone maliciously creating a way into the system, but someone accidentally doing it.
For example, if tier 1 support has local admin privileges on workstation, maybe they shouldn't be trusted with the power to accidentally create user accounts with external access permissions.
I would love to see a practical how-to on securely setting up external access with minimal resources.
One thing to think about is that this might change who has access to create accounts that can access the system externally. i.e. now every local admin has that power, when with a VPN that power might be a bit more naturally contained. Also, depending on the VPN setup, IT will create VPN user passwords themselves and thus have direct control of their complexity. Although users tend to prefer a SSO VPN method.
However, there is often a disconnect in the VPN strategy. The LAN is trusted, but then unmanaged, untrusted systems are allowed full access to the LAN via the VPN. It doesn't make sense.
The bottom line is that any method used need to be thoroughly thought out and planned. Personally, I think would like to have at least 2 step authentication.
@tim_g said in Dipping Toes Into Programming:
@scottalanmiller said in Dipping Toes Into Programming:
@tim_g said in Dipping Toes Into Programming:
I was playing around with the concept of using PHP and forms to do things with PowerShell (given a Windows Server is running a web server with PHP such as XAMPP).
Lots of potential there.
I can get form data processed by powershell and outputted to a web page.
I didn't do much last night, but I was able to output PING results to the web page, and when I was finished for the night, I put in code so when I refreshed the web page, it shut down my computer.
I'm thinking I could potentially create an internal web app to control anything via PowerShell by use of forms... such as adding a user to AD to running reports. (of course secured and login required)
So basically recreating Honolulu?
If that's how it work, I haven't looked... then yes.
Except this would be a learning tool for me as I'm going through my PHP book, where I implement things as I learn them.
That's what I'm doing now with this other PHP web application.
Applying what you're learning to something you already know - it's a good learning strategy
I've used pdftk and pdfsam for merging before.
@lakshmana said in Mangolassi Access Issue:
Actually from today morning i have issue in accessing menu bars in Mangolassi where no output is coming while clicking in my phone Chrome browser. Any facing this issues?? There are notifications are there where i am unable click on it
I also have this issue, I just assumed I needed to clear the cache.
Also using mobile Chrome
Yeah, I think you're going to have to gut Windows. But on Windows 10 you can't ever do an upgrade or it will try and bring everything back.
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
@flaxking said in Windows Desktop Licensing: Cannot be used as a server:
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
@flaxking said in Windows Desktop Licensing: Cannot be used as a server:
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
It would mean that we could use any protocol over the Internet. There is no such thing as an Internet protocol. Things like HTTP and FTP were local LAN protocols first. The Internet made them popular and useful, of course.
The web refers to specific protocols at layer 7. But Internet refers only to the layer 3 + connected to the specific public network called the Internet.
Unless Microsoft tells us they're defining it differently, ^^^ this must be it
I think so. Feels nutty BUT I bet they could explain some logic.... like this is just enough for some development thing or to cover some specific use case but so generally useless that they lose no money.
So you would have to expose to the internet but filter to your public IP in order to be compliant and use it as something functional.
Right. Or just know that there were no internal users. The licensing doesn’t require a strict enforcement system.
Oh, I meant because it's probably pretty much useless to have something public facing with only 20 connections available
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
@flaxking said in Windows Desktop Licensing: Cannot be used as a server:
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
It would mean that we could use any protocol over the Internet. There is no such thing as an Internet protocol. Things like HTTP and FTP were local LAN protocols first. The Internet made them popular and useful, of course.
The web refers to specific protocols at layer 7. But Internet refers only to the layer 3 + connected to the specific public network called the Internet.
Unless Microsoft tells us they're defining it differently, ^^^ this must be it
I think so. Feels nutty BUT I bet they could explain some logic.... like this is just enough for some development thing or to cover some specific use case but so generally useless that they lose no money.
So you would have to expose to the internet but filter to your public IP in order to be compliant and use it as something functional.
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
It would mean that we could use any protocol over the Internet. There is no such thing as an Internet protocol. Things like HTTP and FTP were local LAN protocols first. The Internet made them popular and useful, of course.
The web refers to specific protocols at layer 7. But Internet refers only to the layer 3 + connected to the specific public network called the Internet.
Unless Microsoft tells us they're defining it differently, ^^^ this must be it
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
Reading the EULA more closing, it never refers to sharing. So this implies that you can use a desktop to serve up to 20 users over the Internet, but not internally.
Ok, so that's the interesting part. I believe is it using it as an term to refer to protocols that at one time would only have been used over the internet and not over the LAN. Which seems to be how IIS uses the term, since it's not like they're trying to tell people not to use IIS over the LAN.
But if we take it literally today, we can now use these protocols over the Internet, but not over the LAN.
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
@flaxking said in Windows Desktop Licensing: Cannot be used as a server:
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
Examples of other common violations:
- Spiceworks or any web application cannot be used from a desktop
- QuickBooks cannot be served from a desktop
- Web pages
More or less anything that you’d want to do. It all requires a server. That’s the entire point of the cheap workstation licenses - you get them dirt cheap compared to a server license but can’t do anything you’d want a server for.
All of the things above are fine as long as you don’t access them from another machine. Which is why they are allowed to be installed.
The EULA does give an exception for Internet information services. Since it's not specifically saying IIS, and any other definition for Internet information services is google-washed, do I assume the definition is the same as the services that IIS is capable of?
Not IIS. It’s for sharing Internet information services which is very specific and totally useless. The only use case for that is as an Internet proxy when using your desktop as a router. Using IIS is not covered by that - that’s a product called IIS but running it on your desktop would not be an Internet service.
The only non-IIS specific references to Internet information services that I can find all relate to web servers. Where are you getting the definition of a proxy service from?
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
Workgroups are a security mechanism and not for what you are thinking. Servers do workgroups too. Workgroups are for when you don’t have AD, not necessarily for not having servers.
Right, I forgot about the use case for workgroups when having servers but no domain.
@scottalanmiller said in Windows Desktop Licensing: Cannot be used as a server:
SQL Server can never be used on a desktop unless it is for use exclusively by that desktop. The moment you connect to SQL Server or any application using sWL Server from another desktop, you’ve violated the EULA.
Use duck logic. Walks like a server, talks like a server, it’s a server.
You need a Server OS and CALs
Luckily we don't actually take responsibility for our client's SQL server. (software company) But we need to make sure our minimum requirements don't violate any licencing.
Might need to push QA to do their testing with MS SQL for Linux too