similar to: Nested Group control doesn't work

Thanks, that's extremely helpful. I searched but wasn't able to find that bug report.... Just to clarify, there are no known workarounds, correct? *Jonathan S. Fisher* *VP - Information Technology* *Spring Venture Group* On Sat, Dec 12, 2015 at 10:06 PM, Andrew Bartlett <abartlet at samba.org> wrote: > On Sat, 2015-12-12 at 10:25 -0600, Jonathan S. Fisher wrote: > > Hey

Here's a random question... would it matter if our domain has trust relationships setup? *Jonathan S. Fisher* *VP - Information Technology* *Spring Venture Group* On Wed, Dec 9, 2015 at 9:34 AM, mathias dufresne <infractory at gmail.com> wrote: > Hi Jonathan, > > You wrote: > domain windows.corp.springventuregroup.com > search windows.corp.*pringventuregroupcom* >

On 21/08/2020 21:40, vincent at cojot.name wrote: > On Fri, 21 Aug 2020, Rowland penny via samba wrote: > >> This works for me: >> >> rowland at devstation:~$ sudo ldapsearch -H >> ldaps://dc01.samdom.example.com -D 'SAMDOM\Administrator' -w >> 'xxxxxxxxxx' -b 'dc=samdom,dc=example,dc=com' >>

OK, sorry, I haven't re-read the whole thread carefully enough. >From what I understand sometimes your DNS request are truncated, asking for machineName.windows rahter than machineName.windows.rest.of.your.domain.tld So you have to find what is cutting your DNS requests. If I'm wrong, don't read the rest :p First I would test my DNS resolution using dig, host or nslookup and check

On 21/08/2020 20:08, Rowland penny via samba wrote: > On 21/08/2020 19:28, Vincent S. Cojot via samba wrote: >> >> Hi everyone, >> >> I have a working Samba AD/DC (4.12.6 on RHEL7.8) setup I'm trying to >> use with OpenShift (a container platform to which RedHat contributes >> - aka OCP). I'm also not too skilled on LDAP even though I've been

Hi everyone, I have a working Samba AD/DC (4.12.6 on RHEL7.8) setup I'm trying to use with OpenShift (a container platform to which RedHat contributes - aka OCP). I'm also not too skilled on LDAP even though I've been running the above for over two years now.. There are typically two steps involved in connecting AD to OCP: 1) declare an OAuth configuration in OCP (requires a bind

Hey Rowland, be kind and avoid passive aggressive comments. I'm just looking to try and get this to work, thanks. If I knew everything already, I wouldn't be here asking questions and trying to solve my own problem. I appreciate your help so far, but if you don't have anything nice say, please just ignore this thread. So: jonathan.fisher at freeradius:~$ sudo hostname -y hostname:

I'm quite confused by this one, as I can't see how this would happen.. but after upgrading my DCs from 4.11.10 to 4.18.5, LDAP searches don't seem to work if they use the :1.2.840.113556.1.4.1941: modifier, aka LDAP_MATCHING_RULE_IN_CHAIN. (Yes, it was a fairly big version jump.. Yes, I should have upgraded much earlier.. Yes, I know 4.19.x is out now as well) Here's a search that

On 02/12/15 16:27, Jonathan S. Fisher wrote: > Great thanks, I'll start digging into that. So your running theory is that > one of the DNS resolution attempts is returning .WINDOWS not . > WINDOWS.CORP.XXX.com? This is not your problem. Rowland > > On Wed, Dec 2, 2015 at 10:07 AM, mathias dufresne <infractory at gmail.com> > wrote: > >> OK, sorry, I

Thank you Kees. On Mon, 6 Nov 2023 at 09:37, Kees van Vloten via samba <samba at lists.samba.org> wrote: > I am currently running at 4.19.2 but I have run 4.18.6 and 4.18.5. I did > not experience any issues with nested group lookups, which many of the > filters rely on. Interestingly, I've now found that (on my current DCs, running 4.18.5), ldbsearch *does* seem to return the

Op 05-11-2023 om 23:25 schreef Jonathan Hunter via samba: > I'm quite confused by this one, as I can't see how this would happen.. > but after upgrading my DCs from 4.11.10 to 4.18.5, LDAP searches don't > seem to work if they use the :1.2.840.113556.1.4.1941: modifier, aka > LDAP_MATCHING_RULE_IN_CHAIN. (Yes, it was a fairly big version jump.. > Yes, I should have

Can't you just disable dnsmasq service? You don't seem to be too much confident in that tool and you have DNS issue... dnsmasq has most certainly a good reason to exist. I just don't know it. In IT for work we generally don't need such tool as infrastructures of companies are meant to be stable. As the clients configuration. So I would start with dnsmasq removal, then I would

Hi Rowland, Sorry about that, the site appears down (for me). Here's another link (although on OCP3.11) https://developers.redhat.com/blog/2019/08/02/how-to-configure-ldap-user-authentication-and-rbac-in-red-hat-openshift-3-11/ Vincent On Fri, 21 Aug 2020, Rowland penny via samba wrote: > On 21/08/2020 19:28, Vincent S. Cojot via samba wrote: >> >> Hi everyone, >>

Hi Jonathan and Andrew, > Reminder of my original LDAP query: > (& > (objectCategory=Person) > (sAMAccountName=*) > (memberOf:1.2.840.113556.1.4.1941:=CN=mygroup,OU=myou,DC=mydomain,DC=org) > ) I came across the same/similar issue yesterday and found the origin that triggered the issue (at least in my case). I've added a response to your bugzilla entry

We had to do a few changes in this area (due to security issues) over that large number of releases, it is entirely possible there was a regression. If you have time and patience, could you back up your DC, restore into a subdirectory (on your DC or on a test box) with 4.11.10 from git, and then do a git bisect between that and 4.18.5. You can run the query locally with bin/ldbsearch -H

Great things to investigate... thank you. Ok, so everything is pingable. I've checked to make sure I can send TCP and UDP traffic between the hosts with netcat. > Does your dhcp server deliver the required info? For DNS? Yes, it tells the client to use 192.168.127.129. I'd be in a world of hurt otherwise! > Does 'hostname -d' return the fully qualified domain name of the

On 01/12/15 16:02, Jonathan S. Fisher wrote: > Well I got one step farther... > > hostname -d and hostname -f now work correctly if I add this line to > /etc/hosts > > /etc/hosts > 127.0.0.1 localhost > 127.0.1.1 freeradius.windows.corp.springventuregroup.com > <http://freeradius.windows.corp.springventuregroup.com> freeradius > > But same error on the

On Fri, 2020-08-21 at 17:51 -0400, Vincent S. Cojot via samba wrote: > Hi Rowland, > > First of all, thank you for taking the time to help me. > I tried your suggestion and all results came up empty. > > Then I did a few lapdsearch(es) and found this: > > 1) This query returns two users: > ldapsearch -H ldaps://dc00.ad.lasthome.solace.krynn:636 -x -W -D >

Op 06-11-2023 om 14:58 schreef Jonathan Hunter: > Thank you Kees. > > On Mon, 6 Nov 2023 at 09:37, Kees van Vloten via samba > <samba at lists.samba.org> wrote: >> I am currently running at 4.19.2 but I have run 4.18.6 and 4.18.5. I did >> not experience any issues with nested group lookups, which many of the >> filters rely on. > Interestingly, I've now

On Mon, 6 Nov 2023 at 14:32, Kees van Vloten <keesvanvloten at gmail.com> wrote: > > > Op 06-11-2023 om 14:58 schreef Jonathan Hunter: > > Interestingly, I've now found that (on my current DCs, running > > 4.18.5), ldbsearch *does* seem to return the expected result, but the > > same query via ldapsearch does not. > > What if you try to use starttls