Microsoft's documentation is quite detailed about how to create a relationship between a client & server, but I haven't been able to find any details as to how to terminate the relationship?
As the server has quite broad rights on the client, I suspect it's a purely server-side thing.
There is no "logging out" of an ActiveSync session, at least from the protocol's perspective. Each call is stateless, so as long as the client device retains the account credentials it can issue another synchronization command at any time.
If you're asking about Exchange administrative configuration relating to ActiveSync, you should try ServerFault instead.
Related
We have a requirement to call other APIs other than graph(like Dynamics, Power Automate etc.,) from our Add-in. All examples in Office Add-in Samples suggest to use bootstrap token and then exchange it to get tokens for subsequent APIs and make calls on the server. This forces all communication from our Add-in to be proxied via our server. This can be a unncessary performance bottle-neck. Can we not send the OBO tokens back to our client side Add-in and call other services directly from the client? Is there a known security issue with this approach?
The "received wisdom" about whether access tokens should be sent to clients or stored on clients has fluctuated over the last 10 -15 years, but in recent years the pendulum has swung pretty decisively to the idea that access tokens should not be on the clients. Client-to-server communication is much more vulnerable than server-to-server communication, because there are a wide variety of well-known ways to attack clients and trick users. At the same time, bad actors don't know when server-to-server communication is going to take place and it is much harder to get access to the server computers on either end of the communication.
I would like to make a IPC between two processes using Windows RPC. Please explain me like I am five how my application should achieve good security. I want to use ncalrpc protocol (processes on the same computer). More exactly:
How my client application knows that the server is trusty?
How my server know if the callee is the trusted one?
What options do I have? I didn't get RpcBindingSetAuthInfo function.
Thanks
For a local connection having the client authenticate the server is fairly hard (for example confirming that some other service did not start in place of the desired program) but having the server identify the client is not, call RpcBindingInqAuthClient and use the username to determine what action to take, or just use RpcImpersonateClient if you can rely on existing secured objects. Most of the RPC security apparatus is for remote connections rather than ncalrpc.
I have a https connection from Client to Server and a malware in client. The malware modifies the message and compromises its integrity. I am using a proxy to check the Integrity of the message after the malware has changed the message and before sending it over the internet to the server.
Now, How can I check the Integrity of the message (Sure that it has not been modified by any Man in the Middle) for the second half of my communication channel(Which is from Client to the Server over the internet).
I see few conventional approaches of CRC or Checksum will help. But I am looking for some non traditional or upcoming approaches. I am new to this area and want to take expert advise about the direction I need to search for answer to my question.
Any pointers would be of great help.
Thanks,
As I mentioned in your other question, if you have an https session, you can't do this.
If you could do it, it's possible your proxy could be the "man-in-the-middle", which is exactly what SSL is designed to prevent.
Also, it's not clear how you expect the malware on the client side is changing the message - your software can always validate the message before it is sent via SSL, and after it's sent, the only thing that should be able to decode it is the server.
I strongly recommend spending some time learning about specific well known client server security patterns rather than trying to invent your own (or trying to hack apart SSL). A great starting point would be just picking through some questions on http://security.stackexchange.com. (A personal favorite there is this question about how do to password security). There are likely some questions/links you can follow through there to learn more about client-server security (and eventually understand why I'm confused about what it is you're trying to do).
If you are required to make up your own for some reason, a possible (but still hackable with enough determination) way of doing validation is to include a checksum/hashcode based on all the values, and make sure the same checksum can be generated server side from the values. You don't need a "middle" to somehow crack the SSL to do this though - just do the validation on the server side.
Now I use the websphere MQ client connect to remote MQ Server(7.0 version) using c#, and occurs a problem of authority,Which is the user running the MQ client application have insufficient authority to access qmgr.Then I use the 'setmqaut' command to grand the user sufficient authority and it works.
I think it's not very convenient and must be a better way.May via adding user's IP in MQ Server? But I have no idea how to do it.
Any suggestions would be greatly appreciated.
Thanks
WebSphere MQ does not perform any authentication. Local applications are authenticated by the operating system and so their ID can be trusted. (By definition, if you cannot trust the local OS authentication then the entire server is compromised.) Just as with local connections, WMQ trusts that the ID connecting remotely is genuine. It is up to the WMQ administrator to determine what level of authentication to employ. In WMQ v7 there are two choices - authenticate with SSL/TLS channels, or use a channel exit to authenticate.
In either case, it is the channel's MCAUSER value that decides what ID is used for authorization. If the MCAUSER is left blank then the channel will use the user ID that the client sends. In your case you received a 2035 error because the client sent an ID that was not in the administrative (mqm) group. Had your client sent the ID 'mqm' (or on Windows 'MUSR_MQADMIN'), the connection would have succeeded. If your program is Java or JMS, the ability to select the ID presented is part of the API. Just tell the QMgr who you want to be.
If you are willing to allow remote connections to execute OS commands on the server, then just put the administrative ID in the channel's MCAUSER. (For example, MCAUSER('mqm') on UNIX/Linux or typically MCAUSER('MUSR_MQADMIN') for Windows.) However, be aware that remote users with admin rights can remotely execute arbitrary OS command-line code using the QMgr. This is a feature of WMQ and not a bug, hence we NEVER recommend this in Production. In fact, I personally recommend that development environments enable security. Waiting until Production to figure out how to authenticate connections and what authorizations are needed often leads to unnecessary deployment delays.
If you want to use IP filtering to mitigate that threat, you can either move to WMQ v7.1 which includes this feature natively, or use an exit such as BlockIP2. Either of these solutions will allow you to create rules that filter incoming connection requests by IP address, user ID, etc.
Note that on a v7.0 QMgr all the channels are unprotected by default. So even if you filter incoming requests on one channel, if the others are left in their default state, anyone can still connect and execute commands as the administrator. For a comprehensive review of all this, please take a look at the Hardening WebSphere MQ presentation at t-rob.net. Scroll down to the v7.0 presentations.
I'm using the MS Winsock control in VB6 and I want to understand things like
"when does the Server Close the
connection (triggering the
Winsock_Close() event), and a
related question:
How do you know
when all the data from a a Post has
been returned?
More info:
I should have mentioned: I've already read the MSDN description, etc., but it doesn't actually explain what's happening. E.g., it explains the the Close() event fires when the Server ends the connection but doesn't explain what would cause the connection to end and whether a broken connection would trigger a Close event, etc.
And none of the MSDN descriptions explain know when all the data has arrived. (I suspect it's the Close even firing).
You might want to try out the following walkthrough
tcp.oflameron.com/
You can find the complete code here
If you have any Qs in particular, plz ask here...
GoodLUCK!!
- CVS
Using the Winsock Control at http://msdn.microsoft.com/en-us/library/aa733709(VS.60).aspx
MSDN Search of "Winsock control" at http://social.msdn.microsoft.com/Search/en-US?query=Winsock+control&ac=8
Documentation Lacks
The documentation will not provide the information you are asking for. This is an ActiveX control that allows you to connect computers through TCP/IP protocol stacks.
The information you want applies to how these computer "talk" (the protocol). That totally depends on the server application and client application that are communicating. For instance, if I am connecting to the FTP Service of another computer, the server will not close the connection until I send the appropriate command or until the server detects an idle connection. On the other hand, some services will close the connection on any invalid command, especially SMTP Servers will tighten security.
You need to check out the documentation of the service you are connecting with. The documentation will tell you how to send commands, command format, response codes, how commands are acknowledge, and so on.
SAMPLE: VBFTP.EXE: Implementing FTP Using WinInet API from VB at http://support.microsoft.com/kb/175179