Brutus on Non-Domain-Members

[Florian G. Pflug]

Hi

I'd need to run Brutus (The server) on a machine which is only connected
to the AD domain controller via a VPN, and operated by a different
company than the AD domain. The optimal solution with regard to security
and performance would probably be to not make the brutus server part of
the active directory domain - however, the brutus howto indicates that
this is (currently?) not possible.

I was wondering if this restriction is a technical necessity, or if
there just hasn't been enough interest in making this happed yet.

greetings, Florian Pflug

[Jules Colding]

Hi Florian,

So you are back :-)

Post by Florian G. Pflug
Hi
I'd need to run Brutus (The server) on a machine which is only
connected to the AD domain controller via a VPN, and operated by a
different company than the AD domain. The optimal solution with
regard to security and performance would probably be to not make the
brutus server part of the active directory domain - however, the
brutus howto indicates that this is (currently?) not possible.

Correct - and the reason is security.

Brutus Server spawns an impersonated process for each authenticated
client. That way the client won't be able to do any more than if the
client in question had been sitting in front of the machine physically
and used the keyboard to log on.

Post by Florian G. Pflug
I was wondering if this restriction is a technical necessity, or if
there just hasn't been enough interest in making this happed yet.

It is a security necessity. The client would execute with the
credentials of the Brutus Server service user if the spawned process
wasn't impersonated, or if Brutus Server didn't spawn a process at all.

It is funny that you ask this specific question though... I've just
been asked the very same question from some fine folks from far away.

Best regards,
jules

[Florian G. Pflug]

Post by Jules Colding
So you are back :-)

Yeah ;-)

Post by Jules Colding
Brutus Server spawns an impersonated process for each authenticated
client. That way the client won't be able to do any more than if the
client in question had been sitting in front of the machine
physically and used the keyboard to log on.

Hm.. are you referring to the client's right on the brutus server
machine, or on the exchange mailbox brutus connects to? I'd envision a
domain-less mode to still log onto exchange using the requesting user's
username and password (The same which are used today when spawning the
client process), but to run the brutus process itself (on the brutus
server machine) as either the brutus user, or guest, or some other
special account.

Post by Jules Colding
It is funny that you ask this specific question though... I've just
been asked the very same question from some fine folks from far away.

Interesting... I guess is not that uncommon for bigger projects
involving brutus that the company in charge of the AD domain does not
want (or is not able to) maintain the server on which brutus is running,
but at the same time don't want other companies to administer a machine
which is part of their AD domain. Or at least this is the political
reason why I'm interested in a domainless mode.

regards, Florian Pflug

[Jules Colding]

Post by Florian G. Pflug

Post by Jules Colding
So you are back :-)

Yeah ;-)

Welcome back then ;-)

Post by Florian G. Pflug

Post by Jules Colding
Brutus Server spawns an impersonated process for each authenticated
client. That way the client won't be able to do any more than if the
client in question had been sitting in front of the machine
physically and used the keyboard to log on.

Hm.. are you referring to the client's right on the brutus server
machine,

The clients rights. The client application is performing operations on
the Brutus Server machine. These operations are done under the
credentials of the client user. It would be bad if an evil client
would go about deleting stuff and sending emails on behalf of the CEO...

Impersonating a client will even guard against bugs in BS as the
client won't be allowed to do acts that is outside the bounds of his
domain privileges.

Post by Florian G. Pflug
or on the exchange mailbox brutus connects to? I'd envision a
domain-less mode to still log onto exchange using the requesting user's
username and password (The same which are used today when spawning the
client process),

Yes, but to do that you need to be connected to the AD.

Post by Florian G. Pflug
but to run the brutus process itself (on the brutus
server machine) as either the brutus user, or guest, or some other
special account.

Post by Jules Colding
It is funny that you ask this specific question though... I've just
been asked the very same question from some fine folks from far away.

Interesting... I guess is not that uncommon for bigger projects
involving brutus that the company in charge of the AD domain does not
want (or is not able to) maintain the server on which brutus is running,
but at the same time don't want other companies to administer a machine
which is part of their AD domain. Or at least this is the political
reason why I'm interested in a domainless mode.

Yes, I'm sure you're right. This situation definitely calls for a
solution that does not compromise security and which also respects the
domain policies of the AD. I'm not sure it is possible without at
least one foot within the network domain door so to speak.

Best regards,
jules

[Florian G. Pflug]

Post by Jules Colding
The clients rights. The client application is performing operations
on the Brutus Server machine. These operations are done under the
credentials of the client user. It would be bad if an evil client
would go about deleting stuff and sending emails on behalf of the CEO...
Impersonating a client will even guard against bugs in BS as the
client won't be allowed to do acts that is outside the bounds of his
domain privileges.

Hm - but couldn't the process handling the request run under some
special account stripped of all privileges?

Post by Jules Colding

Post by Florian G. Pflug
or on the exchange mailbox brutus connects to? I'd envision a
domain-less mode to still log onto exchange using the requesting
user's username and password (The same which are used today when
spawning the client process),

Yes, but to do that you need to be connected to the AD.

Hm - I'm confused now. I'd envision things to work the following
1) Client connects to brutus
2) Brutus forks a process running with the privileges of the account
brutus-handler
3) Client creates a MAPI profile via brutus, indicating the username and
password to be used to connect to exchange.
4) Client comes again, and opens the profile just created.
5) Brutus forks a new process, again running as brutus-handler. This
process connects to exchange using the given MAPI profile.

So basically the account brutus-handler is used as a substitute for the
user's account in domainless mode. To prevent one user from opening a
profile created by another user, the profile could be protected with a
password I think - AFAIK passwords can be set for MAPI profiles, no?

The 100$ question from my point of view and knowledge is:
.) Do steps (3) and (5) even work without the machine being a AD member?
I'd have hoped so since there surely is a way to run MS Outlook on
non-domain members, and have it connect to an Exchange server...

Post by Jules Colding
Yes, I'm sure you're right. This situation definitely calls for a
solution that does not compromise security and which also respects
the domain policies of the AD. I'm not sure it is possible without at
least one foot within the network domain door so to speak.

Maybe there could be a non-domain mode that requires additional
authentication from the client like an extra password or a certificate?
In my case, the client is not a reguar users in front of some GUI app,
but rather a daemon that continually syncs the todos stored in a
third-party application with those stored in exchange.

Thanks for your quick responses and your patience with me - I have very
little experience with Exchange and AD, so I have to resort to some wild
guessings about how these things behave in detail...

regards, Florian Pflug

[Luis Correia]

Hi Florian,

stepping into this discussion from an AD's admin prespective...

Post by Florian G. Pflug

The clients rights. The client application is performing operations on the
Brutus Server machine. These operations are done under the credentials of
the client user. It would be bad if an evil client would go about deleting
stuff and sending emails on behalf of the CEO...
Impersonating a client will even guard against bugs in BS as the client
won't be allowed to do acts that is outside the bounds of his domain
privileges.

Hm - but couldn't the process handling the request run under some
special account stripped of all privileges?

It just doesn't work like that.
You need to be authenticated to the domain first, before attempting to
impersonate some other account.

Post by Florian G. Pflug

or on the exchange mailbox brutus connects to? I'd envision a domain-less
mode to still log onto exchange using the requesting user's username and
password (The same which are used today when spawning the client process),

Yes, but to do that you need to be connected to the AD.

Hm - I'm confused now. I'd envision things to work the following
1) Client connects to brutus
2) Brutus forks a process running with the privileges of the account
brutus-handler
3) Client creates a MAPI profile via brutus, indicating the username and
password to be used to connect to exchange.
4) Client comes again, and opens the profile just created.
5) Brutus forks a new process, again running as brutus-handler. This
process connects to exchange using the given MAPI profile.
So basically the account brutus-handler is used as a substitute for the
user's account in domainless mode. To prevent one user from opening a
profile created by another user, the profile could be protected with a
password I think - AFAIK passwords can be set for MAPI profiles, no?
.) Do steps (3) and (5) even work without the machine being a AD member?
I'd have hoped so since there surely is a way to run MS Outlook on
non-domain members, and have it connect to an Exchange server...

Yes, you can use MS Outlook from a non-member workstation. But,
everytime you open it, you must authenticate into the domain.

It is messy and error prone, and surely not one thing I like to have
in my network.

For the record, I've banned at least two users for doing that.
They now use domain wks to read their mail.

Post by Florian G. Pflug

Yes, I'm sure you're right. This situation definitely calls for a solution
that does not compromise security and which also respects the domain
policies of the AD. I'm not sure it is possible without at
least one foot within the network domain door so to speak.

Maybe there could be a non-domain mode that requires additional
authentication from the client like an extra password or a certificate?
In my case, the client is not a reguar users in front of some GUI app,
but rather a daemon that continually syncs the todos stored in a
third-party application with those stored in exchange.
Thanks for your quick responses and your patience with me - I have very
little experience with Exchange and AD, so I have to resort to some wild
guessings about how these things behave in detail...

I've been working with Windows domains and Active Directory for over
10 years now.
What I can tell you is that if you don't fool around relaxing the
security over the default settings, you're rather safe.
(no jokes about windows and it's insecurities here, i'm only talking
about the AD related security issues)

But feel free to play with it :)

Post by Florian G. Pflug
regards, Florian Pflug

Luis Correia

[Jules Colding]

Post by Luis Correia

Post by Florian G. Pflug

Post by Jules Colding

or on the exchange mailbox brutus connects to? I'd envision a domain-less
mode to still log onto exchange using the requesting user's
username and
password (The same which are used today when spawning the client process),

Yes, but to do that you need to be connected to the AD.

Hm - I'm confused now. I'd envision things to work the following
1) Client connects to brutus
2) Brutus forks a process running with the privileges of the account
brutus-handler
3) Client creates a MAPI profile via brutus, indicating the
username and
password to be used to connect to exchange.
4) Client comes again, and opens the profile just created.
5) Brutus forks a new process, again running as brutus-handler. This
process connects to exchange using the given MAPI profile.

Step 5 is not used. The client process/proxy created in step 2 takes
care of everything.

Post by Luis Correia

Post by Florian G. Pflug
So basically the account brutus-handler is used as a substitute for the
user's account in domainless mode. To prevent one user from opening a
profile created by another user, the profile could be protected with a
password I think - AFAIK passwords can be set for MAPI profiles, no?
.) Do steps (3) and (5) even work without the machine being a AD member?
I'd have hoped so since there surely is a way to run MS Outlook on
non-domain members, and have it connect to an Exchange server...

Yes, you can use MS Outlook from a non-member workstation. But,
everytime you open it, you must authenticate into the domain.
It is messy and error prone, and surely not one thing I like to have
in my network.
For the record, I've banned at least two users for doing that.
They now use domain wks to read their mail.

Exactly. Putting BS outside the domain creates more problems than it
solves. I won't exclude the possibility of a really bright idea, but I
don't think it is possible without the cooperation of the AD which
brings us back to BS better being in the domain from the start.

Best regards,
jules