[Samba] Verify if Samba AD was provisioned with RFC2037

Marco Shmerykowsky marco at sce-engineers.com
Sun Jan 3 19:52:12 UTC 2021


On 2021-01-03 1:58 pm, Rowland penny via samba wrote:
> On 03/01/2021 18:33, Marco Shmerykowsky via samba wrote:
>> 
>> On 2021-01-03 11:38 am, Rowland penny via samba wrote:
>>> On 03/01/2021 15:35, Marco Shmerykowsky wrote:
>>>> 
>>>> 
>>>> On 2021-01-03 10:19 am, Rowland penny via samba wrote:
>>>>> On 03/01/2021 15:05, Marco Shmerykowsky via samba wrote:
>>>>>> 
>>>>>> On 2021-01-03 9:53 am, Rowland penny via samba wrote:
>>>>>>> On 03/01/2021 14:32, Marco Shmerykowsky via samba wrote:
>>>>>>>> Is there a way to confirm whether a samba AD was
>>>>>>>> provisioned using RFC2307?
>>>>>>> 
>>>>>>> All that provisioning with '--use-rfc2307' does is to put
>>>>>>> 'idmap_ldb:use rfc2307' into the first DC's smb.conf (a 'join' 
>>>>>>> doesn't
>>>>>>> do this) and adds the 'ypServ30.ldif' to AD. The first makes DC's 
>>>>>>> use
>>>>>>> uidNumber & gidNumber attributes from AD instead of the xidNumber
>>>>>>> attributes from idmap.ldb. The second makes the Unix attributes 
>>>>>>> tabs
>>>>>>> work in ADUC, only problem is, they no longer exist 🙁
>>>>>>> 
>>>>>>> All of the RFC2307 attributes are in the AD schema by default, 
>>>>>>> even if
>>>>>>> you provision without '--use-rfc2307'.
>>>>>>> 
>>>>>>> Rowland
>>>>>> 
>>>>>> I see.  The reason I ask is that I'm trying to use an extended 
>>>>>> query
>>>>>> in a pfsense/openvpn setup and the query seems to fail. I'm fairly
>>>>>> certain I have the query correct (although I could be wrong).
>>>>>> 
>>>>>> In googling I came across some discussion that RFC2307 can create 
>>>>>> issues
>>>>>> with the extended query (https://redmine.pfsense.org/issues/9527)
>>>>>> 
>>>>> That link seems to refer to IPA and AD is different, For instance 
>>>>> you
>>>>> cannot rely on the 'posix' objectclasses being in AD (in fact 
>>>>> anything
>>>>> that does, is, in my opinion, broken), the 'posix objectclasses are
>>>>> auxiliary objectclasses of Windows objectclasses and as such are 
>>>>> not
>>>>> required.
>>>>> 
>>>>> What is your search query and what do you expect the results to be 
>>>>> ?
>>>> 
>>>> my query is -> 
>>>> memberOf=CN=VPN-Users,CN=users,DC=internal,DC=external,DC=com
>>>> 
>>>> Users who will be allowed access to the VPN are assigned to a 
>>>> security group
>>>> named "VPN-Users".  I then used Softerra's ldapbrowser 
>>>> (www.ldapadministrator.com)
>>>> to look at one of the users in the group and pulled the syntax for 
>>>> the "memberof"
>>>> attribute that listed the VPN-User group.
>>>> 
>>>> I would expect the extend query to validate a user who is a member 
>>>> of the VPN-Users group.
>>> 
>>> OK, I do not have a group called 'VPN-Users', but I do have one 
>>> called
>>> 'vpnusers', so try this (adapted for your setup):
>>> 
>>> ldbsearch -H ldap://samdom.example.com -b
>>> 'dc=samdom,dc=example,dc=com' -s sub
>>> '(&(memberOf=CN=vpnusers,CN=Users,DC=samdom,DC=example,DC=com)(sAMAccountName=rowland))' 
>>> -P
>>> 
>>> or using ldapsearch:
>>> 
>>> ldapsearch -H ldap://samdom.example.com -b
>>> 'dc=samdom,dc=example,dc=com' -s sub
>>> '(&(memberOf=CN=vpnusers,CN=Users,DC=samdom,DC=example,DC=com)(sAMAccountName=rowland))' 
>>> -D 'cn=Administrator,dc=samdom,dc=example,dc=com' -W
>>> 
>>> Both of them work for myself, but the first one doesn't ask for a 
>>> password.
>>> 
>>> Rowland
>> 
>> Using ldbsearch I get the following:
>> 
>> # Referral
>> ref: 
>> ldap://internal.external.com/CN=Configuration,DC=internal,DC=external,DC=com
>> 
>> # Referral
>> ref: 
>> ldap://internal.externak.com/DC=DomainDnsZones,DC=internal,DC=external,DC=com
>> 
>> # Referral
>> ref: 
>> ldap://internal.external.com/DC=ForestDnsZones,DC=nternal,DC=external,DC=com
>> 
>> # returned 3 records
>> # 0 entries
>> # 3 referrals
> 
> If I run:
> 
> ldbsearch -H ldap://samdom.example.com -b
> 'dc=samdom,dc=example,dc=com' -s sub
> '(&(objectCategory=person)(objectClass=user)(sAMAccountName=rowland))'
> -P
> 
> I get (heavily snipped):
> 
> # record 1
> dn: CN=Rowland Penny,CN=Users,DC=samdom,DC=example,DC=com
> objectClass: top
> objectClass: securityPrincipal
> objectClass: person
> objectClass: organizationalPerson
> objectClass: user
> cn: Rowland Penny
> sn: Penny
> ...................
> sAMAccountName: rowland
> memberOf: CN=vpnusers,CN=Users,DC=samdom,DC=example,DC=com
> .........................
> distinguishedName: CN=Rowland 
> Penny,CN=Users,DC=samdom,DC=example,DC=com
> 
> # Referral
> ref: 
> ldap://samdom.example.com/CN=Configuration,DC=samdom,DC=example,DC=com
> 
> # Referral
> ref: 
> ldap://samdom.example.com/DC=DomainDnsZones,DC=samdom,DC=example,DC=com
> 
> # Referral
> ref: 
> ldap://samdom.example.com/DC=ForestDnsZones,DC=samdom,DC=example,DC=com
> 
> # returned 4 records
> # 1 entries
> # 3 referrals
> 
> It doesn't matter whether I run it on a DC or a Unix domain member.
> 
> Perhaps I should mention that 'samdom.example.com' is the DNS domain
> and not a FQDN.
> 
> Rowland

The FQDN is my test case is samba_machine.internal.external.com.

Therefore, I assume I should be replacing samdom.example.com
with internal.external.com

When I do that I get the following:

resolve_lmhosts: Attempting lmhosts lookup for name 
internal.external.com<0x20>
Server ldap/internal.external.com at EXTERNAL.COM is not registered with 
our KDC:  Miscellaneous failure (see text): Server (krbtgt/EXTERNAL
.COM at INTERNAL.EXTERNAL.COM) unknown
gensec_spnego_create_negTokenInit_step: gssapi_krb5: creating 
NEG_TOKEN_INIT for ldap/internal.external.com failed (next[ntlmssp]): 
NT_STATUS_INVAL
ID_PARAMETER
Got challenge flags:
Got NTLMSSP neg_flags=0x62898235
NTLMSSP: Set final flags:
Got NTLMSSP neg_flags=0x62088235
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62088235
NTLMSSP Sign/Seal - Initialising with flags:
Got NTLMSSP neg_flags=0x62088235



More information about the samba mailing list