is not a zone user?

Showing results for 
Search instead for 
Do you mean 
Participant II
Posts: 4
Registered: ‎08-24-2017
#1 of 9 6,805
Accepted Solution

is not a zone user?



I'm running Centrify express on a Linux server connected to a Windows domain controller.


I could auto-zone join but I can't authenticate anything.


I tried to run adquery user <username> but got the following respone back:

<username> is not a zone user


How are zones defined? I know that all users are in a different location in the AD.


The domain is:

For example, the bind user was located under OU=Standard,OU=UserAccounts,OU=Americas,OU=Regions,DC=corporate,DC=company,DC=com


Users we want to authenticate are here:





Best regards Johan

Centrify Guru I
Posts: 2,433
Registered: ‎07-26-2012
#2 of 9 6,759

Re: is not a zone user?

[ Edited ]



Welcome to the Centrify Express forums.

To help you better, can you tell us the Operating system and version and the version of adclient (adinfo -v).


Sounds like you're getting started with Centrify.  Centrify has two operating modes: 

  • Auto Zone mode:   in this mode, all users from the local domain or any trusted domains will be visible and will be able to authenticate to your system.  This mode is very well suited for a regular end-user system, where any valid user should be able to log in.  Auto zone mode is the only mode supported by Centrify Express; this mode does not support one-way trusts.
  • Zone mode:  in this model, users not only need to have a UNIX identity defined in the zone, but to access a system, must have an RBAC role that at least allows them to log in.  This mode is supported by the commercial versions Centrify Infrastructure. This mode supports all kinds of AD architectures.


A simple methodology to test authentication is this:


Assumptions:  Centrify is installed and the system is joined.  No tool like chef/puppet has rolled-back the changes done to the NSS, PAM and Kerberos configuration envionments.

If Express, the user is not in the trusting side of a one-way-trust (not supported).


  1. Check if your system is connected
    $ adinfo -m
    This test is to make sure there are no network issues that impair the communication with AD Domain Controllers.
    If the output is "disconnected" or not joined to any zone, you have work to do.
  2. Check if Kerberos is working
    # Authenticate via Kerberos
    $ /usr/share/centrifydc/kerberos/bin/kinit lisa.simpson
    Password for lisa.simpson@CENTRIFY.VMS:
    # Verify Kerberos TGT
    $ /usr/share/centrifydc/kerberos/bin/klist
    Ticket cache: FILE:/tmp/krb5cc_1040188499
    Default principal: lisa.simpson@CENTRIFY.VMS
    Valid starting       Expires              Service principal
    08/25/2017 21:57:25  08/26/2017 07:57:25  krbtgt/CENTRIFY.VMS@CENTRIFY.VMS
            renew until 08/26/2017 21:57:21
    When you join a system to AD via Centrify, we include optimized versions of MIT Kerberos tools, and we configure the Kerberos environment to work with Microsoft AD (regardless of the complexity).

    When testing, you can go from the "lower level" layers to the "upper level" apps (referencing the OSI model), therefore, since all modern AD authentication happens over Kerberos, his is a useful test, because it allows you to isolate the Identity, Centrify authorization components and the access service (e.g. SSH).
  3. Check to see if the user is known to the system and test with Switch User
    $ id dwirth
    uid=1040188499(dwirth) gid=1040188499(dwirth) groups=1040188499(dwirth)
    $ getent passwd dwirth
    dwirth:x:1040188499:1040188499:Diana Wirth:/home/dwirth:/bin/cdax/bash
    $  adquery user dwirth
    dwirth:x:1040188499:1040188499:Diana Wirth:/home/dwirth:/bin/bash
    $ su dwirth

    The first test with getent, id or adquery will yield the identity of the user; in express mode it will be any user from the local domain or any trusted domains; in zone mode, the user MUST have an identity and be authorized in the zone that the system lives. 
    The second test, uses switch user (su) to elevate to the user;  as long as you don't do this with sudo or as root, you'll be challenged with the AD user's password.  If you know it, you can verify not only the underlying technology (Kerberos), but you are testing the Name Service Switch and Pluggable Authentication Modules subystems for the computer.  This still allows the isolation of a terminal protocol like SSH.
  4. Test Terminal Access (e.g. SSH)
    During this test you attempt to log in via SSH; if you can log in, your're fine; but if you can't, for sure (unless you're running an older version of the agent with filtering enabled) you have an SSH directive (or configuration) stopping you from logging in.
  5. Optional - Test a Graphical Interface
    Remember that when dealing with graphical interfaces, since they are long-running daemons, you are likely to have to reboot the system after installing Centrify.   After reboot, you should be able to type-in (or select an AD user from a list) and use the AD password to authenticate.


Now, after you read this, reassess and determine if the issue is that you may be dealing with a one-way trust or config issue.


This is a good place to get started:



Want to learn more about practical Centrify examples? Check out my blog at
Follow Centrify:
Participant II
Posts: 4
Registered: ‎08-24-2017
#3 of 9 6,745

Re: is not a zone user?

Hi Robertson,


Thank you for your reply. 


I have validated the setup and it seems to work this far, 



root@redacted-host:~# adinfo -m
root@redacted-host:~# /usr/share/centrifydc/kerberos/bin/kinit redacted-user
Password for redacted-user@some.domain.COM:
root@redacted-host:~# /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: redacted-user@some.domain.COM

Valid starting       Expires              Service principal
08/26/2017 10:49:42  08/26/2017 20:49:42  krbtgt/some.domain.COM@some.domain.COM
        renew until 08/27/2017 10:49:34



This part works perfectly fine, it's the next step that fails 


root@redacted-host:~# id redacted-user
id: redacted-user: no such user
root@redacted-host:~# getent passwd redacted-user
root@redacted-host:~# adquery user redacted-user
redacted-user is not a zone user

Since I joined the domain I have restarted the host. 

Participant II
Posts: 4
Registered: ‎08-24-2017
#4 of 9 6,744

Re: is not a zone user?

After my last post, I read your message again and ran adinfo -v and noticed I was using 5.4.0


I upgraded to CentrifyDC 5.4.1-455 and restarted the server.


I can now run adquery for my users and my authentications using PAM module works again as expected. 


Before my issues started I did adleave and adjoin towards another domain and all checks was "Pass". 


It must been something that went wrong and the upgrade must have fixed something. 


Thank you for your support. 


Regards Johan

Centrify Guru I
Posts: 2,433
Registered: ‎07-26-2012
#5 of 9 6,737

Re: is not a zone user?



We are happy that you managed to get things fixed.


Based on the information, perhaps you are using an OS that was not compatible/validated with 5.4, but since has been incorporated to 5.4.1;   since you were able to use Kerberos succesfully, but weren't able to enumerate the user's identity, all points to an issue with the Name Service Switch environment.


All is good.


*****Moderation notice (all posters): Always include the operating version;  this way we can do a better assessment.  Linux-like systems have variations; AIX, HP-UX and Solaris are all different, and let's not even get started with OS X.

For example, this could have been an OS X user trying an early version of High-Sierra or any of these OSs:

  • Amazon Linux AMI - latest version (x86_64)
  • CentOS 6.9 (x86_64)
  • Oracle Linux 6.9 (x86_64)
  • RHEL 6.9 (x86_64)
  • Ubuntu 17.04 (x86_64)

Which support was included in 5.4.1



Want to learn more about practical Centrify examples? Check out my blog at
Follow Centrify:
Participant II
Posts: 4
Registered: ‎08-24-2017
#6 of 9 6,732

Re: is not a zone user?

Actually, I'm running Ubuntu 14.04 on that host, have been using two different AD in the past.


I just have to accept "something" happened and the upgrade fixed it. I'm happy with that =)

Participant II
Posts: 5
Registered: ‎09-27-2018
#7 of 9 3,088

Re: is not a zone user?

I'm having this problem with some users and others can login in the same PC.

Linux Debian 9.5


$adinfo -m

$ adinfo -v
$ adinfo (CentrifyDC 5.5.1-400)


$ /usr/share/centrifydc/kerberos/bin/kinit ad-user
Password for ad-user@DOMAIN.LAN:
$ /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_830472692
Default principal:ad-user@DOMAIN.LAN

Valid starting Expires Service principal
28-09-2018 11:15:58 28-09-2018 21:15:58 krbtgt/DOMAIN.LAN@DOMAIN.LAN
renew until 29-09-2018 11:15:45


$ id ad-user
id: ‘ad-user’: no such user
$ getent passwd ad-user
$ adquery user ad-user
ad-user is not a zone user


This same user can login in another PC. It happens in another PC with others users.


Centrify Guru I
Posts: 2,433
Registered: ‎07-26-2012
#8 of 9 3,067

Re: is not a zone user?



Welcome back to Centrify.


Note that you are adding a comment to a thread that has been resolved.  In the future, try a new thread.


In your case, are you running in zone mode or in workstation (Auto Zone/Express) mode?  (adinfo --zone)


You can always kinit (obtain a Kerberos TGT) regardless of the user being valid for the system (valid = resolvable, authorized to log in), since you're bypassing the NSS and PAM stacks. 


However, as your output demonstrates, does not mean that the user is valid for the system.  Possible causes:

In Auto Zone - user is not in a favorable side of a one-way trust (Kerberos will work because KDCs are available and configured).

In Zone Mode:

a) User may not have a UNIX profile (e.g. login, UID, GID, Home, GECOS, Shell).

b) User is not authorized to log in (e.g. does not have the PAM right).

c) Incorrectly created role.

d) User's role assignment has expired.



Want to learn more about practical Centrify examples? Check out my blog at
Follow Centrify:
Participant II
Posts: 5
Registered: ‎09-27-2018
#9 of 9 3,028

Re: is not a zone user?



i'm running in Auto Zone Mode Express

# adinfo --zone
Auto Zone


The same user that I receive the msg  "No passwd entry for user"  when I  "su" the user, can login on another PC without problem. So, there is no problem on the Samba AD. And in this PC that I receive this error msg, I can login with others users.

This problem happens in 4 PC, some users can login in one PC and in another can't, for exemple:

user1 can login on pc1 but can't login on pc2

user2 can't login on pc1 but can login on pc2


# adinfo -g
adinfo (CentrifyDC 5.5.1-400)
Host Diagnostics
  uname: Linux efi-cli-03 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u5 (2018-09-30) x86_64
  OS: Debian
  Version: 9.0
  Number of CPUs: 4
IP Diagnostics
  Local host name: cli-03
  Local IP Address:
    Not found in DNS!Make sure it is in Reverse Lookup Zone.
  FQDN host name:cli-03.domain.lan
Domain Diagnostics
  Domain: domain.lan
  Subnet site: Default-First-Site-Name
    DNS query for: _ldap._tcp.domain.lan
    Found SRV records:
  Testing Active Directory connectivity:
    Domain Controller: srv-ad.domain.lan
      ldap:      389/tcp - good
      ldap:      389/udp - good
      smb:       445/tcp - good
      kdc:        88/tcp - good
      kpasswd:   464/tcp - good
      ntp:       123/udp - good
  Domain Controller: srv-ad.domain.lan:389
    Domain controller type: Windows 2008 R2
    Domain Name:            DOMAIN.LAN
    isGlobalCatalogReady:   TRUE
    domainFunctionality:           4 = (DS_BEHAVIOR_WIN2008_R2)
    forestFunctionality:           4 = (DS_BEHAVIOR_WIN2008_R2)
    domainControllerFunctionality: 4 = (DS_BEHAVIOR_WIN2008_R2)
  Forest Name: EFILTROS.LAN
    DNS query for: _gc._tcp.DOMAIN.LAN
  Testing Active Directory connectivity:
    Global Catalog: srv-ad.domain.lan
      gc:       3268/tcp - good
  Domain Controller: srv-ad.domain.lan:3268
    Domain controller type: Windows 2008 R2
    Domain Name:            DOMAIN.LAN
    isGlobalCatalogReady:   TRUE
    domainFunctionality:           4 = (DS_BEHAVIOR_WIN2008_R2)
    forestFunctionality:           4 = (DS_BEHAVIOR_WIN2008_R2)
    domainControllerFunctionality: 4 = (DS_BEHAVIOR_WIN2008_R2)
  Forest Name: DOMAIN.LAN
Retrieving zone data from domain.lan
  Could not get domain RIDs from adclient: Bad data
Computer Account Diagnostics
  Joined as: cli-03.domain.lan
  Trusted for Delegation: false
  Use DES Key Only: false
  Key Version: 2
  Service Principal Names: cifs/cli-03
Supported Encryption Type(s): DES-CBC-CRC
Operating System Version: 6.1:9.0

System Diagnostic
  Failed to get sysinfo from adclient.

Centrify DirectControl Status
  Running in connected mode
Licensed Features: Disabled


This user I get the error msg "No passwd entry for user", but he can retrieve info from AD


# adinfo -u user1
Active Directory password:
Local host name: efi-cli-03
Joined to domain: efiltros.lan
Joined as: efi-cli-03.efiltros.lan
Pre-win2K name: efi-cli-03
Current DC: efi-srv-ad.efiltros.lan
Preferred site: Default-First-Site-Name
Zone: Auto Zone
Last password set: 2018-09-24 20:28:28 -03
CentrifyDC mode: connected
Licensed Features: Disabled


Maybe it's a sync problem. Is there a way to resync the CentridyAD client


Tks for your help