> On 13 Dec 2017, at 15:03, Jakub Hrozek via FreeIPA-users 
> <freeipa-users@lists.fedorahosted.org> wrote:
> 
> On Mon, Dec 11, 2017 at 10:47:44PM +0200, Alexander Bokovoy wrote:
>> On ma, 11 joulu 2017, Henrik Johansson via FreeIPA-users wrote:
>>> 
>>> 
>>>> On 11 Dec 2017, at 16:04, Alexander Bokovoy via FreeIPA-users 
>>>> <freeipa-users@lists.fedorahosted.org> wrote:
>>>> 
>>>> On ma, 11 joulu 2017, Henrik Johansson via FreeIPA-users wrote:
>>>>> Hi again,
>>>>> 
>>>>> I have generated debug, both in samba and in sssd and attached the log 
>>>>> files. From what I can see from the sssd-logfile we are talkin to the AD 
>>>>> domain but does not find any groups? The rest for the debug files are 
>>>>> from the whole session including the trust-add. If you could have a quick 
>>>>> look at it I would be grateful since pretty much stuck here.
>>>>> 
>>>>> Terminal output:
>>>>> # ipa -v trust-add --type=ad ad.test.net --admin aduser
>>>>> ipa: INFO: trying https://ipaserver.idm.test.net/ipa/session/json
>>>>> ipa: INFO: [try 1]: Forwarding 'schema' to json server 
>>>>> 'https://ipaserver.idm.test.net/ipa/session/json'
>>>>> ipa: INFO: trying https://ipaserver.idm.test.net/ipa/session/json
>>>>> Active Directory domain administrator's password:
>>>>> ipa: INFO: [try 1]: Forwarding 'trust_add/1' to json server 
>>>>> 'https://ipaserver.idm.test.net/ipa/session/json'
>>>>> -----------------------------------------------------
>>>>> Added Active Directory trust for realm "ad.test.net"
>>>>> -----------------------------------------------------
>>>>> Realm name: ad.test.net
>>>>> Domain NetBIOS name: AD
>>>>> Domain Security Identifier: S-1-6-42-491525448-2008367481-725548543
>>>>> Trust direction: Trusting forest
>>>>> Trust type: Active Directory domain
>>>>> Trust status: Established and verified
>>>>> 
>>>>> # ipa trust-fetch-domains ad.test.net
>>>>> ----------------------------------------------------------------------------------------
>>>>> List of trust domains successfully refreshed. Use trustdomain-find 
>>>>> command to list them.
>>>>> ----------------------------------------------------------------------------------------
>>>>> ----------------------------
>>>>> Number of entries returned 0
>>>>> ----------------------------
>>>>> [root@ipaserver samba]# ipa trustdomain-find ad.test.net
>>>>> Domain name: ad.test.net
>>>>> Domain NetBIOS name: AD
>>>>> Domain Security Identifier: S-1-6-42-491525448-2008367481-725548543
>>>>> Domain enabled: True
>>>>> 
>>>>> Domain name: corp.ad.test.net
>>>>> Domain NetBIOS name: CORP
>>>>> Domain Security Identifier: S-1-6-42-2417082233-1637723082-1916539915
>>>>> Domain enabled: True
>>>>> ----------------------------
>>>>> Number of entries returned 2
>>>>> 
>>>>> ]# ipa -v group-add-member ad_users_external --external 'AD\Domain Users'
>>>>> ipa: INFO: trying https://ipaserver.idm.test.net/ipa/session/json
>>>>> [member user]:
>>>>> [member group]:
>>>>> ipa: INFO: [try 1]: Forwarding 'group_add_member/1' to json server 
>>>>> 'https://ipaserver.idm.test.net/ipa/session/json'
>>>>> Group name: ad_users_external
>>>>> Description: AD users external map
>>>>> Failed members:
>>>>>  member user:
>>>>>  member group: AD\Domain Users: trusted domain object not found
>>>>> -------------------------
>>>>> Number of members added 0
>>>> 
>>>> Did you try with a different group/user? Because Domain Users is a bit
>>>> special group in AD, it is Domain Global group. Your logs show that a
>>>> search done by SSSD against AD DC does not end up with any 'cn=domain
>>>> users' result.
>>> 
>>> Yes, i’ve tried with a few groups and the user I am using to create the 
>>> trust witch, no luck.
>> Is there any additional policy applied on AD side that prevents a TDO to
>> access information about AD users/groups?
>> 
>> Something like 
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/VQZAHMM54XNKEWWE32N2RGLANS2DHCSZ/
>>  ?
> 
> I'm sorry for the late reply, but in general I agree with Alexander.
> 
> Could you run a test with ldapsearch? Something like:
> kinit -kt 'IDM$@AD.TEST.NET <mailto:IDM$@AD.TEST.NET>' 
> /var/lib/sss/keytabs/ad.test.net.keytab
> ldapsearch -Y GSSAPI -H ldap://ADSERVERC.corp.ad.test.net 
> <ldap://ADSERVERC.corp.ad.test.net> -b dc=corp,dc=ad,dc=test,dc=net 
> '(&(sAMAccountName=domain\20users)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0))))'
> 
> if this doesn't find anything (and the search base and the server are as
> expected), could you re-run the same search binding as some known user
> with their password?
> 
> btw note that the ldapsearch is looking for POSIX attributes, is that
> expected? Do all users you search for have uidNumber set?

I had tested both, we have posix attributes in the AD schema. I seems to have 
stumbled over a solution to the problem while debuting. I seems that sssd was 
caching something even when we where unable to lookup anything, and it did nod 
invalidate the cache after several weeks, reboots or when removing trusts. 
After removing /var/lib/sss/db/* and restarting sssd it seems to work as 
expected. Thanks for all the help!

Regards
Henrik


_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to