0

We have a public reachable Debianserver running Nextcloud, where our users should logon with their AD credentials. This server is in a DMZ and hardned as much as possible but I'm a bit worried about the need to allow LDAP Querys from the nextcloud to the DC in our internal network. The account used to make these querys is only used for this, has no special privileges and a long, complex password. Is there anything more I can do to harden this point? I thought about putting a RODC in this DMZ and sync only the needed accounts to this server but i'm not sure if that realy helps (or make it maybe even worse).

404_username_not_found
  • 3
  • 2

3 Answers3

0

If your concern is about object visibility in queries, Active Directory has List Object Mode which can provide this functionality. This is typically compared with denying access to group(s) of user accounts in a multi-tenant scenario.

https://social.technet.microsoft.com/wiki/contents/articles/29558.active-directory-controlling-object-visibility-list-object-mode.aspx

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
  • object visibilty is one point but my biggest concern is the inbound rule for LDAP(S) from a potentially compromised system to my DC. So if the Linux server is fully compromised could an attacker use this connection to compromise our AD? – 404_username_not_found Jan 27 '23 at 12:55
  • @404_username_not_found: LDAP queries are rarely the source of an incursion for threat actors (assuming there isn't anything stupid like user accounts with SPN's that shouldn't have them). A DC should not be placed in a DMZ for this. That is a physical security issue that doesn't make sense given all they need is access to port tcp/636 and/or tcp/3269 to query an LDAP directory. DMZ's are inherently hostile (they exist primarily to block outgoing access), most organizations where security is a priority this would not pass the operational readiness tests for bringing a DC online. – Greg Askew Feb 15 '23 at 11:13
  • @404_username_not_found: What some organizations do for this is use "shadow" forests to have copies of the user accounts/attributes. This is common in some Microsoft service scenarios. Some organizations have multiple shadow forests. Those are typically synchronized with production (without security information). – Greg Askew Feb 15 '23 at 11:14
  • thanks for your comment. This sounds realy interesting! – 404_username_not_found Feb 17 '23 at 14:29
0

an RODC is an excellent idea for this. You should also set up firewall access control lists to only allow ldaps connections from the specific ldap client on the remote network.

For the rest, follow your system security best practices for securing internet facing hosts (keep the software up to date, monitor logs, etc etc).

natxo asenjo
  • 5,739
  • 2
  • 26
  • 27
-1

Some basics: use LDAPS if you haven't enabled LDAPS yet; Use certificate authenticate if you can; Trust you already know not to use simple bind.

strongline
  • 620
  • 3
  • 10
  • How does LDAPS and certificate based authentication work in this scenario? – vidarlo Jan 25 '23 at 14:29
  • There is no difference how cert based auth works in an internal network, or from DMZ. Make sure 1. port 636 is open; 2. DC and client trust each other's issuing CA; 3. client cert has its SAN defined with UPN; 4. cert is mapped to respective user. Once you have done these, you then don't have to provide userName/password – strongline Jan 25 '23 at 19:47
  • Let me rephrase: how does it improve security? – vidarlo Jan 25 '23 at 19:59
  • If I need to explain how LDAPS is more secure than LDAP, or how cert based is more secure than u/p, then I rather not explain. Sorry – strongline Jan 25 '23 at 20:06
  • In the scenario provided I don't see any significant value in TLS. The threat vector is not eavesdropping, but rather someone breaking the machine that runs the client. TLS won't help an iota in this case. – vidarlo Jan 25 '23 at 20:08
  • last comment of mine: what you mentioned is legit, but you are making assumption of what OP's concern is; and completely just disregard the risk of eavesdropping. – strongline Jan 25 '23 at 20:10
  • No, I don't make assumtions. I base it on what he writes in his question. He asks for hardening suggestions where he has an externally accessible server that queries internal systems. I don't see how this answers that question. – vidarlo Jan 25 '23 at 20:12
  • Correct me if I'm wrong, but I believe eavesdropping is in this case not a big concern, because the DMZ only contains this server and the firewall. If you compromised my Linux machine you can simply use the stored information (certs or PWs) to make querys – 404_username_not_found Jan 27 '23 at 13:02