We have a system using two machines to do some processing. Let's call the machine that does the processing PROCESSOR, and the machine giving it items to process SERVER. Both are running Windows Server 2008. We have one Windows Service running on SERVER which needs to use MSMQ to send messages to a public queue PROCESSOR.
On PROCESSOR, we have another Windows Service which pulls items from the queue for processing.
The two machines are in the same domain, and all works fine if we run both services under accounts with domain admin privileges. However, we need the accounts to have the minimum privileges possible (particularly for the service on SERVER).
Before elevating the rights of the account we're using for the service on PROCESSOR, I tried giving it full rights to MSMQ. However, this didn't seem to be enough, and as soon as the service tried to do anything with MSMQ (first thing it does on starting is to check if relevant queues exist), I got an exception saying "Access to Message Queuing is denied".
Does anybody know what permissions need to be granted to an AD account in order for it to be able to use MSMQ?
Thanks,
Andrew
Run your service under a defined system account, like (I believe Network), then set the permissions on the MSMQ to full control for that.
When I've used this in the past I just cheated and allowed access to "Everyone". But in a domain setting the best way is to create a domain user and set that for the service and permissions on the MQ.
You need to set permissions on the objects in Active Directory.
So you'll need Get Properties permission if you are querying objects, for example.
This should be on the MSMQ object under the computer object and the queue object(s) under the MSMQ object.
Also, the defaults are going to be restricted to allowing everyone to send but not receive so you will need to add that access for the domain account you are using to be able to read messages.
Related
In a multi-domain-setting, I want to collect security file access audit events at a central place.
In ActiveDirectory, it is possible to enable file access auditing at the Domain Controller by creating a GPO.
Additionally, at a different 'file server' computer, that is a member of one of the domains, a SACL has to be configured at the file system objects that I want to be audited (and that are included in a network share).
Once this is done, the file access events are recorded and somehow magically transfered to the event log of the domain controller.
I would really like to know:
How and when are these events transfered? Is the transfer
encrypted?
Is it possible to directly select another (additional) receiver of those events, apart from the domain controller? I know that it is possible to forward those log events later on, but are they by default forwarded to the Domain Controller? Is there an implicit forwarding configured?
How much traffic is going to be generated, with respect to network load?
First thing domain controller is server having Active Directory(a kind of organisation database). Active directory identified every component/resources connected into domain whether logical(user) and physical(computer and printer) as a object. This object has properties known as Schema. This schema has been catalog in repositories known as GC(Global catalogue) but gc has only partial information so that resources can be located.
Now, coming to this policies. There is two thing GPO and OU. GPO is set of policies that you can apply on OU or higher grouping unit.
Let's see how communication happen. Again, there is two widely used term 1. replication and 2. LDAP Query.
Replication is done between controller so that network traffic can be reduced and for higher availability for resources connected to server. In replication, all resource information has synchronized with server. To ensure security integrity, there is certificate(which gives identification as well encryption mechanism) and delegation(providing rights).
LDAP is protocol through which user has been authenticated. So LDAP has query which quiet similar to other query language. Well all this query has been logged ultimately to server.
GPO has been replicated on resources or you can apply forcibly. If you want to do it immediately.
I've generated an AD-LDS instance on a Windows Server 2008 R2 and successfully connected to it via ADSI Edit on a windows 7 machine (both computers are situated on the same domain).
My goal is to create a lightweight .NET program that will be run by all domain users and determine whether a specific user can or cannot perform a certain action (roles & groups).
So far i've managed to write most of it, but i'm now facing a small security issue: althought no credentials are required when running from the server itself, when running from another user (in the same domain, ofcourse), LDS connection requires the instance's administrator credentials - and i'm not too keen to leave this kind of thing lie around in my code.
I've search the web quite a lot for a way to bypass that (Active Directory binding? / SimpleBinding?), but all solutions i found involved SSL and certificate installations.
Is there a simple way for a user in the domain to connect the LDS instance without exposing his/the server's credentials?
Thanks.
Have you looked at permissions in the instance itself? There are groups you can add principals to. It sounds like you're running the code locally as the user that installed LDS which by default gets all sorts of perms, but other users were not granted enough rights (secure by default and all that).
I've recently taken over a script from someone who's left the company and it recently started failing. The code looks up a specific user and sends them an e-mail.
I've nailed the culprit line that fails to be (user and passwords is set to my personal account):
my $dbh = DBI->connect('dbi:ODBC:IDM', $idm_user, $idm_passwd)
from this database the script selects the E-mail from a specified user login name.
I can't seem to find any documentation on the database IDM and was wondering if anyone knows of it?
Is it a built in Microsoft Exchange DB or Windows domain DB?
Thanks!
That line is connecting to an ODBC data source called IDM defined in the ODBC data source administrator in that system.
Ewww...
I have a feeling that the guy wrote his own database to do this particular task, and maintained that database.
I had to do something like this and used Net::LDAP to read the user's email address from the Windows Active Directory, then used Net::SMTP to write the email. Of course, your Windows Active Directory must be configured to allow for LDAP access, and your Outlook email must be configured to allow for SMTP based mail.
You can try something like Win32::AD::User to fetch the user's email address directly from Active Directory, but I have a feeling that you won't have read/write access to it.
If you can figure out how to fetch the user's information, you can try Mail::Outlook to write the actual email.
I never used either of these modules. I guess I've been lucky that my Window sites allow LDAP access and SMTP.
My objective is to prevent direct user access to the database server. One way is to create a WCF service or web service in the middle between the front end application and the database server.
First of all, the users will be authenticated to the application. Subsequently the application will connect through the WCF service to perform business logic operations. The WCF service will perform the database related operations by using one windows account. This will prevent other users to directly access the database server, since the permission will only be granted to specific one windows account.
Here are my questions : Even though the database access is only granted to one windows account and the WCF will use this windows account to perform database related operations, is it possible to mark all database related operations with the credential of the logged in user ?
Update
Thanks for the replies. Seems like the above scenario is not achievable. I am currently exploring the SQL 2008 Application Role feature. One of the example is here. But after further exploration, apparently there is an issue with the connection pooling.
Update
There is a stack overflow thread here regarding SQL Server Application Role
You'd have to have every user set up in sys.server_principals to enable context switching like EXECUTE AS which would mean that they have direct db access anyway.
If you enabled kerberos/delegation, the same applies. Links One and Two
You'd have to pass in the user name as a parameter on each SQL call, or use CONTEXT_INFO perhaps.
Note: every MS Office user has MSQRY32.EXE which acts as a query tool. If you want no direct DB access, then you need to ensure there are no permissions set or granted
Depends.
If your database and WCF service are on the same box and you do a lot of jiggery pokery to impersonate then it is possible. As soon as you move your DB to another box then it stops working.
This is a known limitation and the reason is impersonation will create a token which will get you to a box but this is not passable to another box. I tried to find the Q&A where MS guy had answered but still havent been able to. Whenever I find it, will update.
Typical ISP setup. One server is the web server, another is the DB SQL server. There is a local administrator account, let's say XYZ, created on both machines. So when I log in remotely, I am either WebServer\XYZ or DBServer\XYZ, depending where I log in.
Now, when I login to SQL Server SSMS on DBServer using Windows Authentication, and execute "SELECT SUSER_NAME()", I get DBServer\XYZ. That makes sense since it's picking up the fact that I logged in with those credentials.
Now, move over to the WebServer. I remotely login as WebServer\XYZ. I've installed the SQL client components there. When I launch SSMS, choose the DBServer, login with Windows Authentication, and execute "SELECT SUSER_NAME()", I somehow get DBSERVER\XYZ, instead of what I would assume should be WebServer\XYZ.
Somehow, the XYZ from the WebServer becomes the XYZ from the DBServer. Why is that? How does that happen? Surely, it can't just be because the names happen to be the same?
I've heard of trusted domains, but neither machine is a Domain Controller, so I don't have access to that info. How can I tell if it's trusted or not, without the GUI tools?
The reason I ask the question is because, I'm trying to implement the same thing on my XP laptop (using Virtual PC), so I can imitate the production environment, but I'm not having any luck.
The NTLM challenge between machines is a little more complex #Quassnoi indicates but it is similar. The machines may well be in the same domain or trusted domains, but the accounts you are using are local machine accounts, scoped only to the local machine's security access management.
Local SAM accounts patterned as machinename\userid are non-propagatable. You'd experience a series of negotiated fallbacks when you tried to authenticate against external resources using that account as follows:
Pass current domain/username/password hash token - it'll fail, the account is untrusted
Fallback - revert passing hash of UserID + Password
Fallback - revert to connecting as anonymous credentials.
The fallbacks can also be disabled through configuration, it is very common for anonymous authentication to be prevented.
As #Quassnoi indicates in this instance you managed to login using the #2 fallback.
To enable account credentials to propagate, you'd need the following to be true:
machines would need to be members of domains with at least one-way trust between each other (they don't necessarily have to be members of the same domain).
use domain accounts - not local machine accounts - would look something like domainname\userid. A special case is the Network Service account which has a proxy account in the domain scenario - domainname\machinename$.
How do you tell if your machine is a member of the domain? It's pretty easy if you've got interactive login to the machines. There are a few strategies
interactively the System control panel will show workgroup or domain membership. (Right-click properties on Computer in the start menu)
at the command-line, IPCONFIG /ALL will also show the default DNS prefix which is typically the same as your domain name.
I suspect your ISP would create a domain just to make it easy to manage and monitor their machines. Whether they'd let you create domain accounts is a different question.
You XYZ accounts seem to have same passwords on both machines, and they are not a part of a domain.
WebServer sends just XYZ as a username and answers all password challenges successfuly, as the passwords do match.
DbServer, of course, thinks of you as of DbServer/XYZ, as it knows of no others.
Exactly same thing happens when you try to access one standalone machine from another one over SMB. If your usernames and password match, you succeed.