search for: compromiss

On Tue, 24 Apr 2018 09:50:10 +0200 Denis Cardon via samba <samba at lists.samba.org> wrote: > A more expeditive way is to delete and recreate the zone using the > samba-tool dns zonedelete / zonecreate. The SRV entries are recreated > when the server restart. You should just be careful about having your > kerberos configuration properly so it does not needs DNS to find its

...on options are barely minimal. Currently, Enabling Bind-DLZ gives bind9 process RW access to all the samba LDB files (the equivalent of NTDS.DIT if you come from the MSAD world) without any filtering, so it has access to all NTLM hashes, all Kerberos hashes, and krbtgt account. So if you have a compromission in Bind9 process, it could escalate directly to full domain compromission. It also prevent enabling any SELinux configuration on the DC. There has been some mail about this isolation issue. The solution would be to use standard LDAP access between Bind9 and Samba processes. It would resolve...

I am considering which DNS implementation and cannot determine exactly when someone should use the Bind9 manner with BIND9_DLZ Module. For my purposes, I will have AD and non-AD nodes on the network using either DHCP or static IP addresses. Some will be Windows & Linux clients joined on the Samba AD domain for logins. Some will be Windows & Linux clients that are standalone using

...ave in a large multi-site setup with slow VPN and strict firewall rules. > I have read your join howto and have the following comments, based on > my experience. > > I would also install libpam_winbind and libpam_krb5 we are limiting at much as possible shell connection to the AD (a compromission on your AD is a compromission of your whole network). So we don't enable this kind of authentication on DC. SSH key exchange for the lucky few that manage the AD is much better suited IMHO. > /etc/krb5.conf needs to be only this: > > [libdefaults] > default_realm = MONDOM...

...nimal. > > Currently, Enabling Bind-DLZ gives bind9 process RW access to all the > samba LDB files (the equivalent of NTDS.DIT if you come from the MSAD > world) without any filtering, so it has access to all NTLM hashes, all > Kerberos hashes, and krbtgt account. So if you have a compromission in > Bind9 process, it could escalate directly to full domain > compromission. It also prevent enabling any SELinux configuration on > the DC. > > There has been some mail about this isolation issue. The solution > would be to use standard LDAP access between Bind9 and Samb...