× Welcome to the Centrify Community! We are rolling out product name changes — click here to learn more.

domain trust not working all the time

Showing results for 
Search instead for 
Do you mean 
Reply
Participant II
Posts: 9
Registered: ‎07-26-2010
#1 of 9 1,588

domain trust not working all the time

Hello,

  We have 2 domains with a trust both ways and normally the authentification works correctly wether we have a user from a domain1 or from domain2. However, sometimes for some unknow reason the authentication doesn't work for some users.

 

  From what we've seen, this only seems to happen a user from domain2 is trying to log to a machine connected on domain1. It doesn't happen all the time but when it does even restarting centrify doesn't fix the issue. I checked with adinfo that it is connected, adinfo -T doesn't show any problem and adinfo -g in the domain info map I see both domains. All seems to indicate that it should be working but it's only working on the « local » domain.

 

I activated the centrify debugging and rand the id command:

/usr/share/centrifydc/bin/addebug on
/usr/share/centrifydc/bin/addebug clear
id qwertyuiop
/usr/share/centrifydc/bin/addebug off

adinfo -v
adinfo (CentrifyDC 5.3.1-398)

 

I'm including some of the logs. Any idea what's going on?

 

Thanks for your help.

 

Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:18 id(20730)> -> getpwnam_centrifydc_r  user="qwertyuiop"
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:18 id(20730)> User="qwertyuiop" str2ent=(nil) result=0x7f713a67f260, buffer=0x14d0060
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:18 id(20730)> User 'qwertyuiop' is not an override user
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <main> daemon.ipcserver Accepted new lrpc2 client on <fd:21> with flags 0x00000802
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > daemon.ipcclient2 executing request 'NSSGetPasswdDataByName' in thread 139758834870016
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > daemon.ipcclient2 Getting passwd data for 'qwertyuiop'
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.adagent Find GUID: 72136703214c4d24ab8ce0806e949adb (7)
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.objecthelper age 25, expire age 3600, cutoff time 0, refresh 5, negative=true, cacheOps 7
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.adagent findObject ADNames: qwertyuiop#012name: qwertyuiop type=SAM domain=domain1.lan
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.bind.cache ADCB::search base , filter (&(objectClass=User)(|(objectCategory=Person)(objectCategory=Computer))(sAMAccountName=qwertyuiop)), attrs 2 (cacheOps=7, GC=0)
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.objecthelper age 25, expire age 3600, cutoff time 0, refresh 5, negative=true, cacheOps 7
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.bind.cache ADCB::search base , filter (&(objectClass=User)(|(objectCategory=Person)(objectCategory=Computer))(sAMAccountName=qwertyuiop)), attrs 1e (cacheOps=7, GC=1)
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.objecthelper age 25, expire age 3600, cutoff time 0, refresh 5, negative=true, cacheOps 7
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.adagent findByAttr: Not Found:qwertyuiop category:user attr=sAMAccountName
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.bind.cache ADCB::search base , filter (&(objectClass=User)(|(objectCategory=Person)(objectCategory=Computer))(displayName=qwertyuiop)), attrs 2 (cacheOps=7, GC=0)
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.objecthelper age 25, expire age 3600, cutoff time 0, refresh 5, negative=true, cacheOps 7
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.bind.cache ADCB::search base , filter (&(objectClass=User)(|(objectCategory=Person)(objectCategory=Computer))(displayName=qwertyuiop)), attrs 1e (cacheOps=7, GC=1)
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.objecthelper age 25, expire age 3600, cutoff time 0, refresh 5, negative=true, cacheOps 7
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.adagent findByAttr: Not Found:qwertyuiop category:user attr=displayName
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.bind.cache ADCB::search base , filter (&(objectClass=User)(|(objectCategory=Person)(objectCategory=Computer))(cn=qwertyuiop)), attrs 2 (cacheOps=7, GC=0)
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.objecthelper age 25, expire age 3600, cutoff time 0, refresh 5, negative=true, cacheOps 7
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.bind.cache ADCB::search base , filter (&(objectClass=User)(|(objectCategory=Person)(objectCategory=Computer))(cn=qwertyuiop)), attrs 1e (cacheOps=7, GC=1)
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.objecthelper age 25, expire age 3600, cutoff time 0, refresh 5, negative=true, cacheOps 7
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.adagent findByAttr: Not Found:qwertyuiop category:user attr=cn
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.adagent findObject: NotFound:qwertyuiop Category:user
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > base.objecthelper 'qwertyuiop' is not a canonical name
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > util.except (NotFound) : No such unix user 'qwertyuiop' (reference ipcclient2.cpp:936 rc: 0)
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > daemon.ipcclient2 No user data: No such unix user 'qwertyuiop'
Feb 22 09:42:19 dantzig07 adclient[20276]: DEBUG <fd:21 NSSGetPasswdDataByName > daemon.ipcclient2 request 'NSSGetPasswdDataByName' complete

 

 

Centrify Guru I
Posts: 1,784
Registered: ‎07-26-2012
#2 of 9 1,577

Re: domain trust not working all the time

Looks like you have a negative result on the NSS query for that user

 

Several questions to ask here....

 

You posted in the Express forum, are you working with the freemium version of the product?  (I ask because sometimes folks that are using the commercial version post here too)

 

What happens when you do an `adquery user -A qwertyuiop` ?

Can you tell me the OS/version and show me the passwd line of the /etc/nsswitch.conf file?

Does this happen in some or all systems?

Is your AD normalized?  (e.g. is there a quertyuiop in another domain in the forest)

 

What happens when you rebuild the cache  (adflush --force) and wait?

 

Thanks!

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Participant II
Posts: 9
Registered: ‎07-26-2010
#3 of 9 1,570

Re: domain trust not working all the time


Looks like you have a negative result on the NSS query for that user

 

I tried a few other users as well, those on the local domain all worked, those on the second domain didn't.

 

You posted in the Express forum, are you working with the freemium version of the product?

 

We're using centrify express, not the commercial version.

 

What happens when you do an `adquery user -A qwertyuiop` ?

 

adquery user qwertyuiop
qwertyuiop is not a zone user
adquery user qwertyuiop -A
Error: No such user qwertyuiop

 

Can you tell me the OS/version

 

# cat /etc/oracle-release
Oracle Linux Server release 7.3

 

and show me the passwd line of the /etc/nsswitch.conf file?

 

passwd: centrifydc files sss

It's worth checking, but I think if this was an nsswitch problem, local domain users wouldn't work either.

 

Does this happen in some or all systems?

 

Some and not all the time. We had 1 system that would « forget » about a user and after some adflush, adquery, he usually came back but might disapear again later. For some unknown reason, the problem eventually stopped happening on that machine.

 

Is your AD normalized?  (e.g. is there a quertyuiop in another domain in the forest)

 

We have 2 forests each with 1 domain. Each user is unique accross forests and domains (except for some admins account that we don't use on Linux).

 

What happens when you rebuild the cache  (adflush --force) and wait?

 

I suspect this might fix the problem but it might come back later or appear on another machine. I'm trying to figure out why this happens and if it's possible to do something so it doesn't happen anymore.

 

Thanks a lot for your help.

 

 

Centrify Guru I
Posts: 1,784
Registered: ‎07-26-2012
#4 of 9 1,565

Re: domain trust not working all the time

@pg379,

 

Thanks for providing this information. 

 

The only thing I see there is that I assume that you are using a version of the Centrify client that is not fully tested with RHEL derivatives (e.g. Oracle Linux) 7.3 (released Nov 11 2016).

 

Server Suite 2017  (v. 5.4.0) released yesterday, provides support for the following new platforms:

 

o  Windows 10 (x86_64)
o  Mac OS X 10.11 (x86_64)
o  Fedora 23 (x86, x86_64)
o  CentOS 6.7 (x86, x86_64)
o  Oracle Enterprise Linux 6.7 (x86, x86_64)
o  Red Hat Enterprise Linux Desktop 6.7 (x86, x86_64)
o  Red Hat Enterprise Linux Server 6.7 (x86, x86_64)
o  Red Hat Enterprise Linux Server 6.7 (ppc64 – no Power8)
o  Red Hat Enterprise Linux Desktop 7.2 (x86_64)
o  Red Hat Enterprise Linux Server 7.2 (x86_64)
o  Red Hat Enterprise Linux Server 7.0, 7.1, 7.2 (ppc64 – no Power8)
o  Scientific Linux 6.7 (x86, x86_64)
o  Ubuntu Desktop 15.10 (x86, x86_64)
o  Ubuntu Server 15.10 (x86, x86_64)
o  SUSE Linux Enterprise Desktop 11 SP4 (x86, x86_64)
o  SUSE Linux Enterprise Server 11 SP4 (x86, x86_64, ppc64, ia64)
o  Oracle Solaris 11.3 (x86_64, SPARC)

Unfortunately RHEL 7.3 derivatives aren't on the list for now;  although I don't think that's your issue, perhaps you can try with the newer client to see if there are any changes.

 

Otherwise try rebuilding the cache with the adflush or adobjectrefresh commands.

 

R.P

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Participant II
Posts: 9
Registered: ‎07-26-2010
#5 of 9 1,562

Re: domain trust not working all the time


The only thing I see there is that I assume that you are using a version of the Centrify client that is not fully tested with RHEL derivatives (e.g. Oracle Linux) 7.3 (released Nov 11 2016).

 

Hello,

  I don't recall which versions of redhat/centos/oracle linux were supported on the version I downloaded (2016.1) but it's possible 7.3 was not on the list.

 

Server Suite 2017  (v. 5.4.0) released yesterday, provides support for the following new platforms:

 

 Unfortunately RHEL 7.3 derivatives aren't on the list for now;  although I don't think that's your issue, perhaps you can try with the newer client to see if there are any changes.

 

I just checked on the website and saw a that version you mention and it does support OL7.3:
Oracle Enterprise Linux: 5.0-5.11, 6.0-6.8, 7.0-7.3 (64-bit)

So I guess I'll do the update and hope the problem goes away.

 

Otherwise try rebuilding the cache with the adflush or adobjectrefresh commands.

 

I'll keep that in mind if the update doesn't help.

Thanks.

 

 

Participant II
Posts: 9
Registered: ‎07-26-2010
#6 of 9 1,520

Re: domain trust not working all the time

I did the update and the problem remained on that host. I did
adflush
adquery user | grep  qwertyuiop

and it was found.

 

I was hoping I wouldn't have to do that but at least it worked.When the service is restarted, the cache isn't flushed?

 

 

Centrify Guru I
Posts: 1,784
Registered: ‎07-26-2012
#7 of 9 1,462

Re: domain trust not working all the time

[ Edited ]

@pg379,

 

I'm sorry I did not get an update on this thread.

 

I'm not sure I understand, are you saying that the issue went away or not?

If the issue has not been resolved, then we need to debug.  Are you a commercial customer?

 

And yes, I was looking at an earlier version of the RELNOTES and gave you inaccurate information.

The credential cache is renewed when the cache.flush.interval is hit or when there's a negative response;  restarting the client does not imply an automatic flush.

 

Can you please provide the de-identified output of the domain map?  (adinfo -y domain)

Can you provide the ouptut of adinfo -y health?

 

Thanks!!

 

 

R.P

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Participant II
Posts: 9
Registered: ‎07-26-2010
#8 of 9 1,459

Re: domain trust not working all the time



I'm sorry I did not get an update on this thread.

 

No problem.

 

I'm not sure I understand, are you saying that the issue went away or not?

 

The adflush fixed the problem, not the centrify update.

 

If the issue has not been resolved, then we need to debug. 

 

I found another system that has the same behaviour.

 

Are you a commercial customer?

 

No, using centrify express.

 

The credential cache is renewed when the cache.flush.interval is hit or when there's a negative response;  restarting the client does not imply an automatic flush.

 

Ok, good to know.

 

Can you please provide the de-identified output of the domain map?  (adinfo -y domain)

 

# adinfo -y domain
System Diagnostic
========Domain info map========
DC=domain2,DC=lan
    CN              = DOMAIN2.LAN
    SID             = S-1-5-21-2808170103-917183174-659996841
    TRUST_ATTRS     = 0x20
    TRUST_DIRECTION = 3
    TRUST_TYPE      = 2
    NTLM NAME       = DOMAIN2
    LOCAL FOREST    = YES
CN=domain1.lan,CN=System,DC=domain2,DC=lan
    CN              = DOMAIN1.LAN
    SID             = S-1-5-21-3214971259-2964318432-211451886
    TRUST_ATTRS     = 0x8
    TRUST_DIRECTION = 3
    TRUST_TYPE      = 2
    NTLM NAME       = DOMAIN1
    LOCAL FOREST    = NO

 

Can you provide the ouptut of adinfo -y health?

 

# adinfo -y health
System Diagnostic
===============System Health===================
        HealthStatus:   Healthy
        SubSystem:      HostAuth
        ErrCount:       1
        LastSet:        Mon Jan 30 10:05:56 2017
        LastReset:      Mon Jan 30 10:06:29 2017
        LastCode:       1019
        LastReason:     KDC refused skey: Cannot resolve network address for KDC in requested realm
        LastOperation:  Host authenticate

Thanks.
Centrify Guru I
Posts: 1,784
Registered: ‎07-26-2012
#9 of 9 1,376

Re: domain trust not working all the time

[ Edited ]

The only thing I can suggest from the output is that you want to make sure your DNS settings are correct on all systems and that cross forest name resolution is consistent. 

 

Notice the last KDC error.

 

Although you're talking about a 2-way trust, this article outlines all the things that need to be in place for proper functionality:

 

http://community.centrify.com/t5/TechBlog/A-Primer-on-Centrify-and-Active-Directory-External-One-Way...

 

trust-layer-approach.jpg

 

P.S:  Apologies again for our responses being late.  We had an issue with the DL that lets us know if there are new threads or responses lately, but that has been resolved.

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify: