There are tons of online suggestions for setting MSMQ permissions programmatically using .net System.Messaging.MessageQueue SetPermissions method. But I cannot find any system.messaging property that lets me read the permissions currently configured on existing queues.
I'm trying to write a powershell audit script to take stock of dozens of machines configurations, and its almost entirely useless if I can't get the configured permissions for the queues.
I'm open to suggestions for command line options, didn't find anything mentioned in stackoverflow. Yoel's MSMQ WMI provider doesn't expose the necessary info, and as far as I can tell there is no command line provided with MSMQ that gets you this.
Can't believe this is something no one has addressed. Another enterprise product by Microsoft that's missing a fundamental security feature (verification).
Using powershell for the audit, would prefer built in or .net framework solutions, but getting the info by any means necessary (CLI) if need be.
You may be stuck using P/Invoke to call MQGetQueueSecurity. IIRC the COM interface doesn't have support for reading queue permissions either.
I had the same problem and took some of the advice that has been suggested here. I made a small c# project that uses p/invoke to get the user's permissions for a given queue.
Please feel free to use or contribute to it:
https://github.com/jlevitt/MSMQSecurity
Related
My question is related to the recommended way (going forward) to talk to on-premises Exchange mail box and perform operations on it from an external application programmatically?
EWS APIs and the corresponding SDKs look promising based on a few articles such as this :
https://blogs.msdn.microsoft.com/webdav_101/2018/06/19/about-using-ews-and-powershell/
but there is bit of confusion on whether it will continue to be supported in the future based on this:
https://blogs.technet.microsoft.com/exchange/2018/07/03/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/
Although the above talks of just o365, the fact that EWS will no longer be invested in, raises the question if new applications for on-premises exchange should continue to use it.
PowerShell, remote PowerShell etc. also might work but it seems less suited for use/integration within an external application and more so for automating operations.
Could someone please throw some light on what is recommended way going forward to work with on-prem Exchange?
Try the Microsoft GraphAPI. Details https://developer.microsoft.com/en-us/graph/graph-explorer here. Sign in. Try the https://graph.microsoft.com/v1.0/me/messages sample. See more examples by clicking "Show More samples" on the left column after you login.
Is it The Way (tm)? I don't know but is very cool. I have some sample code I'm working with, nothing in a format to share, but look like the API covers a lot of territory. Some client-only rules look like they need some work to expose, maybe they'll get beefed up in later releases.
Depends on the type of Application you are trying to write, EWS is going to be around in Exchange 2019 so it will work just fine talking to say 2013, 16 and 19 OnPrem. There are advantages and disadvantages to using EWS vs. the new REST API's but it is application specific and changing fast. But again it depends entirely on the type of Application you are trying to write and what version of Exchange you need to support. And typically newer features that will appear in new OnPrem versions aren't back-ported into older versions. So a great new feature that will work in Office365 and Exchange 2019 may not work in 2016 and you may need to use some of the older legacy API's to achieve the same thing. Bottom line as of today if you are an ISV and need broad coverage support for versions of OnPrem Exchange expect to need to use both EWS and REST. If you are just creating apps for one organization that's going to be migrating to 2019 in the future you'll probably get away with just REST.
I apologize for my fundamental lack of knowledge in regards to these technologies in advance. I'm having a bit of trouble understanding the whole Azure AD/Authentication process in general, and I don't feel that Microsoft's support documents adequately describe much of the process.
I appears to me that the REST requests themselves are quite simple, and the following page seems to detail them quite well. https://msdn.microsoft.com/en-us/office/office365/api/files-rest-operations
However, what I fail to understand is the authentication process.
My goal here is to determine if what I'd like to do is even possible, so I will begin with that. What I need to be able to do is to be able to make REST API calls from a JSP or potentially a PHP script to access a link to a file located on a user's Onedrive for Business account. To put it simply, I would just like to be able to quickly get a publicly accessible link to a user's file. From the perspective of having access to the REST API, that seems to be a simple task, my challenge is understanding and implementing the capability to do so.
Correct me if I am wrong, but my current understanding of the process goes something like so.
Create an application in Azure AD, you need to define a location for signing on. I'm not certain how this works at all, does the defined location need to be making a request to sign on somehow? Does it need to exist on the same domain? I honestly have no idea the nature of how you actually go about signing in, but it requires some authentication of the application as well.
Once you have signed in, you have access to a 'security token' that has information about the application and what it can access. how is this token stored? A server session, browser cookies?
Somehow you pass this token along with your REST request and it is determined that you have access to the information you are requesting.
I have used pre-made JavaScript file pickers in the past to facilitate the selection of user files for things such as Google Drive and Dropbox, but it doesn't appear as though any such tools exist for Onedrive for Business, so I will need to become familiar with the authentication process myself. Looking into the Microsoft documentation has only served to confuse myself more, and unfortunately all of the examples are for .NET projects as far as I can tell. I am afraid that this means that is it only possible to access this information from a .NET project, but please correct me if this is not the case.
I realize that this question appears extremely ignorant, and that's likely because it is. Moving from JavaScript file pickers to something like this appears to be a significant leap in required technical prowess, and I'm still rather new, so please forgive my inexperience. Most importantly I'd like to know if what I'm looking to do is possible at all, and secondly if there are any readily available resources that are a little more focused than the Microsoft documentation.
Thanks in advance for any assistance.
There are some great resources available for coding for Office 365 and not just those on MSDN.
The best place to start is http://dev.office.com. This is the destination for information on O365 development. You can get to the documentation, training materials and code samples. The code samples have a filter so you can search on a number of properties including language and product. There are samples of course for .net, but also for iOS, Android and PHP, which is what you mention you want to use for your project.
http://dev.office.com/code-samples-detail/2138
This sample connects to the calendar, but the important part is understanding the authentication process for your application to Azure AD. Once you get the authentication working, you can call the other O365 services by getting the resource url to the appropriate resource from the Discovery Service.
If you need more samples, http://github.com/officedev is the place to look. These samples are from Microsoft, the community as well as the code used in Microsoft and community training events and presentations.
If you prefer, some great training courses exist on Microsoft Virtual Academy for Office 365 development. These are online videos that are broken into chapters and sections so you can easily find what you need. They often have labs associated with them as well. I recommend the Intro to Office 365 Development - Section 5 to get a quick overview of the Office 365 APIs and then look at the Deep Dive: Integrate Office 365 APIs in Your Web Apps.
If you still have questions, this is the place to post them. Hope this helps. Reply if you have any questions.
I am configuring two Windows Server 2008 installations to harden them against attack, and there are tons of services, policies, security options, registry settings, to work on.
I'm looking at powershell, batch files, but no luck though (I was hoping to "automate the commands" without going through the tiring process).
I would be glad if anyone could advise me on this.
I'm assuming you already have enough knowledge in the basic Powershell. You can to use wmi objects with Powershell to achieve your tasks.
Take a look at this handy tool: http://technet.microsoft.com/en-us/library/ff730935.aspx
I would also suggest you to use Server Core if you really want to harden servers against attack.
I had this exact problem, posted here on StackOverflow, looked around more and I found a way of modifying GPO's directly (my implementation via Powershell). Its not pretty, but it IS functional for programmatically modifying GPO's: Using Powershell to edit/modify a GPO
Microsoft seems to be heavily pushing that their server applications (i.e SQL Server 2008, Exchange Server, etc) all have some type of PowerShell integration. The logic makes sense in that one can choose to manage the application from a GUI or CLI.
Therefore if one were to follow that trend and want to build an application that had a PowerShell interface, how would one even start?
Has anyone in the community done this type of thing? If so, what seems to be the best approach?
Update:
The UI needs to have a certain look/feel. Therefore, PowerGUI does not lend itself in this situation. However, I've used PowerGUI and do agree that it can help bridge gaps.
Part of the confusion is really whether or not hosting PowerShell is necessary in order to build an application on top of it. From what I've found, it is not (i.e. Cmdlet's). However, I have not seen anyone really discuss this in the answers yet.
Start here: Writing a Windows PowerShell Host Application
Exchange 2007 admin console hosts PS directly, and surfaces every UI action by showing a ubiquitous "and here's the PowerShell you just asked me to do" UI model). SQL Server 2005 & 8 admin consoles demo the concept of surfacing everything in a UI as scripts as a way of dogfooding scripting abilities (but there is little PowerShell support in SQL Server) (Distinction between Exchange and SQL Server's type of support added in response Shaw's comment, thanks)
PowerScripting podcast has a few interviews on topics like this. Also get-scripting podcast
I attended a PowerShell / MMC 3.0 Devlab at Microsoft a few years ago that taught how to do this very thing. The basic idea was to create the "management functionality" via a series of PowerShell cmdlets in a PSSnapin for your application. CLI oriented folks can just load the snapin and party on your cmdlets directly. For the GUI oriented, you build a MMC snapin that hosts a PowerShell runspace which, in response to GUI actions, executes the appropriate PowerShell cmdlets to tweak the application that is being managed. For bonus points, you display what PowerShell code will be executed by the MMC GUI such that the code can be copied and pasted into a script. There are plenty of examples out on the web that show how to host a PowerShell runspace in your (or the MMC) process and execute PowerShell script in that runspace and get back results.
This is an intriguing idea!
I haven't ever thought about it, and I have no idea if I think it's a good idea, but some creative things could be done.
For example, suppose you have some typical administrative-ish piece of software. Don't really care what, specifically. In a classic app dev't scenario, I'd typically try to generate a list of Command objects (things that'd implement some sort of ICommand), and then my UI would bind to those.
Suppose, now, that you were to instead create a cmdlet for each Command. The UI would more-or-less exist as a friendly interface for the core logic in the suite of cmdlets.
Yeah, ok, nothing new here. People've been doing this for a long time, building up GUIs around command-line tools. I think the key difference is that you'd instead be building up individual command line tools from the concept of the application itself. Heck, it might make more sense for both the application and the cmdlets to reference some shared library of commands instead of making the GUI sit on top of the cmdlets themselves.
Errr- sorry for the scatterbrained response. This answer was pretty much purely stream-of-consciousness. :)
You could try primal forms for building a complete application from a script or you need to build your application with an snappin cmdlets (the previous being what is used by sql, exchange etc.) but link to primail forms here
http://www.primaltools.com/products/info.asp?p=PrimalForms
We are discussing development of an improved management infrastructure for our distributed system.
We use COM, web services and .NET components. Since we're based on Microsoft Windows Server XP/2003, I guess, we basically have two options:
Powershell cmdlets
WMI classes using System.Management and WMI providers for native code (class, instance, method, event)
Why would we choose Powershell over WMI?
I would choose PowerShell over WMI for the following reasons:
Writing a cmdlet is only adding a .NET Class.
The PowerShell runtime provides command line parsing built in.
Writing your management interface in PowerShell allows administrators the ability to integrate management of your application with that of other applications and services (like Exchange, Active Directory, or SQL Server).
The PowerShell environment makes the pipeline available to administrators, enabling management tasks for your application to be done more efficiently.
Discoverability. PowerShell, via Get-Command, Get-Member, and Get-Help, provides an extremely discoverable environment for admins to work in, resulting in a shorter learning curve to maintaining your application.
Even if you go the WMI route, PowerShell does have support for working with WMI (though there are a few glitches).
To me, PowerShell is the best way to surface a task oriented interface to an application. With the support Microsoft has been providing PowerShell, it is and will be a consistent interface to managing applications and services throughout the enterprise.
My day job is as an admin and I'm pushing all the vendors I work with towards surfacing a PowerShell management API, as this makes the learning curve and context switching for managing applications much lower. On the development side, I have written (and am still working on) a series of PowerShell cmdlets for one open source product I work with and am working on another set for a separate application.
Jeffrey Snover answers the "why PowerShell" here. The post is in the context of SQL, but very much applicable here.
I'm not sure I'd make the decision. It's not exactly either-or... you can choose to do both.
WMI can be consumed by a number of different things, not just PowerShell. Why not write your management instrumentation in PowerShell, and then wrap that WMI in some task-oriented cmdlets to make things easier on administrators? That's what some MS product teams are choosing to do, especially when they have other consumers of WMI they want to continue supporting.
If you've already got suitable .NET code, turning that into a cmdlet may be faster than turning it into a WMI provider. If that's the case, and speed is a concern, go with what's easier. But no matter what you do, you can always wrap it in a PowerShell cmdlet for admins, which is definitely the recommended approach.
Not sure that this can be answered with the information that you have provided so far. My gut feeling would be that you should use powershell since it sounds like you may already have some .Net code. But it really does just depend on exactly what you are trying to do.