is not a zone user?

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

is not a zone user?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-24-2017 03:58 AM
Hi,
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: corporate.company.com
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:
OU=EMEA,OU=Standard,OU=UserAccounts,OU=Americas,OU=Regions,DC=corporate,DC=company,DC=com
or
OU=US,OU=Standard,OU=UserAccounts,OU=Americas,OU=Regions,DC=corporate,DC=company,DC=com
Best regards Johan
Solved! Go to Solution.
Re: is not a zone user?
[ Edited ]- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-25-2017 08:14 PM
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).
- Check if your system is connected
$ adinfo -m connected
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. - 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). - 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 Password: [dwirth@engcen6]$
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. - 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. - 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: http://community.centrify.com/t5/TechBlog/TIPS-A-Centrify-Server-Suite-Cheat-Sheet/bc-p/25707
R.P
Follow Centrify:




Re: is not a zone user?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2017 02:28 AM
Hi Robertson,
Thank you for your reply.
I have validated the setup and it seems to work this far,
root@redacted-host:~# adinfo -m connected 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 root@redacted-host:~#
Since I joined the domain I have restarted the host.

Re: is not a zone user?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2017 02:36 AM
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
Re: is not a zone user?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2017 06:25 AM
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
R.P
Follow Centrify:




Re: is not a zone user?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-26-2017 09:52 AM
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 =)
Re: is not a zone user?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
09-28-2018 07:33 AM
I'm having this problem with some users and others can login in the same PC.
Linux Debian 9.5
$adinfo -m
connected
$ 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.
Re: is not a zone user?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
09-28-2018 12:16 PM
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.
R.P
Follow Centrify:




Re: is not a zone user?
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
10-03-2018 05:46 PM
Robertson,
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 (CentrifyDC 5.5.1-400)
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
Local host name: cli-03
Local IP Address: 172.16.3.61
Not found in DNS!Make sure it is in Reverse Lookup Zone.
FQDN host name:cli-03.domain.lan
Domain: domain.lan
Subnet site: Default-First-Site-Name
DNS query for: _ldap._tcp.domain.lan
Found SRV records:
srv-ad.domain.lan:389
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
Joined as: cli-03.domain.lan
Trusted for Delegation: false
Use DES Key Only: false
Key Version: 2
Service Principal Names: cifs/cli-03
cifs/cli-03.domain.lan
ftp/cli-03
ftp/cli-03.domain.lan
host/cli-03
host/cli-03.domain.lan
DES-CBC-MD5
RC4-HMAC
AES128-CTS-HMAC-SHA1-96
AES256-CTS-HMAC-SHA1-96
System Diagnostic
Failed to get sysinfo from adclient.
Centrify DirectControl Status
Running in connected mode
adinfo
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