Thanks Kequa.

On the way to retrieve the provisioning script, I discovered the problem.
The password associated to the ID used to provision was blank, gone, diappeared.

Once I replaced the ID and password, everything sprung up roses.

Thanks again

Hello Fingers24,

Thank you for providing your resolution! I am happy to hear you were able to locate the missing details from the Samanage application.

Feel free contact support at anytime if you require additional assistance.

Hope you have a great day. :)

Kindly,

Kequa

Hello,

All of these users had their synchronizations working fine.  No new policy changes were pushed, as this setting has remained the same from "day 1".  Is there any kind of logging that would show someone making a policy change, so we can track that down?  Since all of these users are 2-factor users, they have to use an App-Specific password to get the authentication working (which they all had done months and months ago), but out of the blue, last Friday, the 23rd, some were being prompted for that app-specific password again, and we have no idea why.

I looked at the Google logs to see if there were any failure attempts at logging in for the affected users, which might cause Google to ask for the password again, and there was nothing.  All of their mail checking all came from our IP, and there was nothing in the logs that looked like there was any hacking attempts on these users.

It was about 8 out of 30 or so users that were affected, and they were a mix of iOS 9.3.x and 10.x, so it doesn't seem to be iOS related.  None of our Android users were affected, and there were users from two separate device policies, so it wasn't like a single policy was to blame.

At this point, they are working again, but I am trying to look into any logs that Centrify has that might point to something around the date/time they started getting prompted for the password again.  Where can I find a log that might give me this info?

Many thanks,

Bruce

I've been using Centrify Express 2015 on my Linux (CentOS, Ubuntu, Amazon Linux, etc.) systems for the past year to bind them to AD.  Users are able to SSH into their Linux VMs via SSO using the Kerberized version of putty and selecting "Attempt Kerberos auth..." and selecting the UPN as the Auto-login username.  It's been create, very simple and it just works :-)

I have a project spinning up that is using RHEL 7.2.  I noticed there was an updated version of Centrify Express that supports this version, so I downloaded and installed Centrify Express 2016 Update 1 installed on a few RHEL 7.2 test VMs.  I am able to join the systems to AD and login with a username/password without issue.  When I attempt attempt to open SSH to one of these test VMs from my terminal server using the kerberized version with "Attempt Kerberos auth..." enabled and selecting the UPN as the Auto-login username I see a message like this:

Using Kerberos authentication
Using principal user-da@child.domain.me
Got host ticket host/servername.child.domain.me@CHILD.DOMAIN.ME
login as user-da@CHILD.DOMAIN.ME

Kerberos authentication failed.  Please check
1) Unix login name is correct
2) Target service principal name is correct
3) Kerberos authentication is enabled in SSH server
4) Clock in the host is syncrhonized with the clock in AD

 I've verfied DNS is setup correctly (forward & reverse lookups match) and the SPN attribute of the associated computer object is populated:

nfs/servername.child.domain.me
nfs/servername
http/servername.child.domain.me
http/servername
host/servername.child.domain.me
host/servername
ftp/servername.child.domain.me
ftp/servername
cifs/servername.child.domain.me
cifs/servername

Adinfo shows that I am connected to AD and adquery user finds the user if I use the UPN or the Samaccountname:

[ec2-user@servername ~]$ sudo adinfo -aV
Options:
-------
task: all
domain: null
output: null
additional paths: null
user: null
using user's credential cache: Yes
allow password prompt in kerberos get init credential: Yes
user's credential cache: FILE:/tmp/krb5cc_cdc0_Ecu27b
server: null
Local host name: servername
Joined to domain: child.domain.me
Joined as: servername.child.domain.me
Pre-win2K name: servername
Current DC: dc02.child.domain.me
Preferred site: CHS-Core
Zone: Auto Zone
 Retrieving site information from site=any, server='dc02.child.domain.me'
 Using machine credentials
 Using principal name 'servername$@CHILD.DOMAIN.ME'
 Binding to child.domain.me, cache=MEMORY:0x120b360
 Searching for (&(samAccountName=servername$)(objectClass=computer))
 in dc=CHILD,dc=DOMAIN,dc=ME
 Found computer account: CN=servername,OU=PROD,OU=Servers,OU=TNM,OU=CHS Programs,dc=CHILD,dc=DOMAIN,dc=ME
Last password set: 2016-09-27 21:33:51 EDT
CentrifyDC mode: connected
Licensed Features: Disabled
[ec2-user@servername ~]$ adquery user user-da@child.domain.me -A
unixname:user-da
uid:1895826512
gid:1895826512
gecos:John Smith DA
home:/home/user-da
shell:/bin/bash
auditLevel:AuditIfPossible
isAlwaysPermitLogin:false
dn:CN=John Smith DA,OU=Domain Admins,OU=Administrators,dc=CHILD,dc=DOMAIN,dc=ME
samAccountName:user-da
displayName:John Smith DA
sid:S-1-5-21-4262317619-3503357892-2585303325-1104
userPrincipalName:user-da@child.domain.me
canonicalName:child.domain.me/Administrators/Domain Admins/John Smith DA
passwordHash:x
guid:5a7b32da-5238-4c42-bfb8-497b704700d5
requireMfa:false
zoneEnabled:true
unixGroups:user-da,denied_rodc_password_replication_,domain_admins,domain_users,igsg_di-rdsfarm_users,igsgcommoncoreserveradmins,igsgisserveradmins,igsgowiserveradmins,igsgserveradmins
memberOf:child.domain.me/Administrators/IGSGServerAdmins,child.domain.me/Sub OU/Common Core/Groups/IGSGCommonCoreServerAdmins,child.domain.me/Sub OU/IS/Groups/IGSGISServerAdmins,child.domain.me/Sub OU/OWI/Groups/IGSGOWIServerAdmins,child.domain.me/DI/EAD/Groups/IGSG DI-RDSFarm Users,child.domain.me/Users/Denied RODC Password Replication Group,child.domain.me/Users/Domain Admins,child.domain.me/Users/Domain Users
[ec2-user@servername ~]$ adquery user user-da -A
unixname:user-da
uid:1895826512
gid:1895826512
gecos:John Smith DA
home:/home/user-da
shell:/bin/bash
auditLevel:AuditIfPossible
isAlwaysPermitLogin:false
dn:CN=John Smith DA,OU=Domain Admins,OU=Administrators,dc=CHILD,dc=DOMAIN,dc=ME
samAccountName:user-da
displayName:John Smith DA
sid:S-1-5-21-4262317619-3503357892-2585303325-1104
userPrincipalName:user-da@child.domain.me
canonicalName:child.domain.me/Administrators/Domain Admins/John Smith DA
passwordHash:x
guid:5a7b32da-5238-4c42-bfb8-497b704700d5
requireMfa:false
zoneEnabled:true
unixGroups:user-da,denied_rodc_password_replication_,domain_admins,domain_users,igsg_di-rdsfarm_users,igsgcommoncoreserveradmins,igsgisserveradmins,igsgowiserveradmins,igsgserveradmins
memberOf:child.domain.me/Administrators/IGSGServerAdmins,child.domain.me/Sub OU/Common Core/Groups/IGSGCommonCoreServerAdmins,child.domain.me/Sub OU/IS/Groups/IGSGISServerAdmins,child.domain.me/Sub OU/OWI/Groups/IGSGOWIServerAdmins,child.domain.me/DI/EAD/Groups/IGSG DI-RDSFarm Users,child.domain.me/Users/Denied RODC Password Replication Group,child.domain.me/Users/Domain Admins,child.domain.me/Users/Domain Users

If I select the username portion of the UPN or the Samaccountname for the auto-login username, I am able to login without issue:

Using Kerberos authentication
Using principal user-da@CHILD.DOMAIN.ME
Got host ticket host/servername.child.domain.me@CHILD.DOMAIN.ME
login as user-da
Successful Kerberos connection
Created home directory
[user-da@servername ~]$

By chance has anyone else run into this?  I'm only experiencing this on REHL and not on any other distros of Linux....I'm stumpped.

Thanks!

Welcome back to the Community portal GarlockPrinting!

I would like to get a better understanding of the issue so that I can provide the appropriate root cause of the issue. 

1. Which Google application you are referring to where the issue occurred for the password prompt?

2. After the end user entered the App-specific password, did the prompt for a password only occur when attempting to access thier mailbox? 

3. Did the issue occur at the configured mailbox under Settings > Mail > Accounts on the iOS device?

As far as capturing the logs, the Centify application has the ability to enable debug at Settings > Log Settings. You can enable debug logging and also send the log file to a specified e-mail address.

Another method for capturing iOS device logs can be accomplsihed by gathering the console logs from the device. You can do so by completing the following steps:

1. Open the mobile application on the iOS device
2. Click the Settings button.

3. Under the Log Settings section, choose the Log Level and change it to Debug and click the button to enable Log to Console

B) Collect console logs using the following based on your iOS version:

Xcode 6 (for iOS 8 and above)
iPhone Configuration Utility (for iOS 7 and below)

Kindly,

Kequa

Hello, I am trying to mount an nfs share and getting permission denied.

Server is Ubuntu16LTS and the export is

/home   xx.xx.xx.xx(rw,insecure,sync,no_subtree_check,sec=krb5)

Client is MacOS Sierra and automount is:

*      -fstype=nfs,sec=krb5,rw         128.40.150.110:/home/&

on the server I get:

Sep 29 12:06:29 ubuntu16-yh rpc.mountd[4805]: authenticated mount request from xx.xx.xx.xx:976 for /home/ucftxxx (/home)

but on client when executing 

cd /home/ucftxxx

I get

permission denied

both server and client are joined to AD by Centrify Express, so I would think the user (ucftxxx) would have the same id on both system and not expect permission denied issue.

any help?

Thanks,

Yusah.

,

Welcome to the Centrify Express forums.

Thanks for providing the information.  This is a great example on how to provide background information on a post.

I just installed a RHEL 7.2 system in one of my test environments and was unable to reproduce.  Granted, I only have one domain (not a child domain like your outputs suggest).

Here's the installation (note that I installed Centrify-enhanced OpenSSH)

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)

# yum install centrifydc-5.3.1-rhel4-x86_64.rpm centrifydc-openssh-7.2p2-5.3.1-rhel4-x86_64.rpm -y
Loaded plugins: product-id, search-disabled-repos, subscription-manager
Examining centrifydc-5.3.1-rhel4-x86_64.rpm: CentrifyDC-5.3.1-398.x86_64
Marking centrifydc-5.3.1-rhel4-x86_64.rpm to be installed
Examining centrifydc-openssh-7.2p2-5.3.1-rhel4-x86_64.rpm: CentrifyDC-openssh-7.2p2-5.3.1.391.x86_64
Marking centrifydc-openssh-7.2p2-5.3.1-rhel4-x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package CentrifyDC.x86_64 0:5.3.1-398 will be installed
---> Package CentrifyDC-openssh.x86_64 0:7.2p2-5.3.1.391 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

===============================================================================================================================================================
 Package                            Arch                   Version                          Repository                                                    Size
===============================================================================================================================================================
Installing:
 CentrifyDC                         x86_64                 5.3.1-398                        /centrifydc-5.3.1-rhel4-x86_64                                80 M
 CentrifyDC-openssh                 x86_64                 7.2p2-5.3.1.391                  /centrifydc-openssh-7.2p2-5.3.1-rhel4-x86_64                 4.5 M

Transaction Summary
===============================================================================================================================================================
Install  2 Packages

Total size: 85 M
Installed size: 85 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : CentrifyDC-5.3.1-398.x86_64                                                                                                                 1/2
  Installing : CentrifyDC-openssh-7.2p2-5.3.1.391.x86_64                                                                                                   2/2
  Verifying  : CentrifyDC-openssh-7.2p2-5.3.1.391.x86_64                                                                                                   1/2
  Verifying  : CentrifyDC-5.3.1-398.x86_64                                                                                                                 2/2

Installed:
  CentrifyDC.x86_64 0:5.3.1-398                                           CentrifyDC-openssh.x86_64 0:7.2p2-5.3.1.391

Complete!

# adjoin -w -c "ou=computers,ou=centrify"  -u user centrify.vms
user@CENTRIFY.VMS's password:
Using domain controller: dc.centrify.vms writable=true
Join to domain:centrify.vms, zone:Auto Zone successful

Centrify DirectControl started.
Loading domains and trusts information

Initializing cache
.
You have successfully joined the Active Directory domain: centrify.vms
in the Centrify DirectControl zone: Auto Zone


You may need to restart other services that rely upon PAM and NSS or simply
reboot the computer for proper operation.  Failure to do so may result in
login problems for AD users.

When trying to log in using PuTTY, no issues:

Using Kerberos authentication
Using principal bootcamp.admin@CENTRIFY.VMS
Got host ticket host/rhel72.centrify.vms@CENTRIFY.VMS
login as bootcamp.admin@CENTRIFY.VMS
BOOTCAMP
This system is for authorized use and for training purposes.
Successful Kerberos connection
Created home directory
[bootcamp.admin@rhel72 ~]$

I then removed Centrify-enhanced OpenSSH

yum erase CentrifyDC-openssh-7.2p2-5.3.1.391.x86_64
Loaded plugins: product-id, search-disabled-repos, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package CentrifyDC-openssh.x86_64 0:7.2p2-5.3.1.391 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

===============================================================================================================================================================
 Package                            Arch                   Version                         Repository                                                     Size
===============================================================================================================================================================
Removing:
 CentrifyDC-openssh                 x86_64                 7.2p2-5.3.1.391                 @/centrifydc-openssh-7.2p2-5.3.1-rhel4-x86_64                 4.5 M

Transaction Summary
===============================================================================================================================================================
Remove  1 Package

Installed size: 4.5 M
Is this ok [y/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Erasing    : CentrifyDC-openssh-7.2p2-5.3.1.391.x86_64                                                                                                   1/1
centrify                                                                                                                                | 2.9 kB  00:00:00
  Verifying  : CentrifyDC-openssh-7.2p2-5.3.1.391.x86_64                                                                                                   1/1

Removed:
  CentrifyDC-openssh.x86_64 0:7.2p2-5.3.1.391

Complete!

Retried again

Using Kerberos authentication
Using principal bootcamp.admin@CENTRIFY.VMS
Got host ticket host/rhel72.centrify.vms@CENTRIFY.VMS
login as bootcamp.admin@CENTRIFY.VMS
Successful Kerberos connection
Last login: Thu Sep 29 11:30:45 2016 from 192.168.81.11

Can you confirm something for me?  It seems you're using stock SSH.  Can you test with Centrify-enhanced OpenSSH and report your findings?

We add a lot of optimizations for situations where you have multiple forests, child domains, etc.

R.P

In part three of this blog, I continued the discussion of using the mkComputerRoles.tcl script with a ComputerRoles.csv definition file to add AD accounts to the User Groups. I showed how to add the AD account to the User Groups from the passwd files, as listed in the ComputerRoles.csv file. As an alternative, I also showed how to add the AD accounts to the User Groups as explicitly defined in a “map file”.

In this final blog of the series, I will show how to implement an enhanced separation of duties model with the mkComputerRoles.tcl script.

Active Directory OU Structure for an Enhanced Separation of Duties Model

The Centrify best practices OU structure is designed to implement a basic separation of (administrative) duties model (this was discussed in part 1). In some cases, however, the need exists to implement a more granular separation of (administrative) duties model. One method of achieving this granularity of separation of (administrative) duties is to store the UNIX computer objects, User Groups and Computer Groups in OUs based on the required separation of duties. Then, create distinct AD security groups and delegate to them the required AD rights to manage objects in those OUs.

For example, suppose there is a need to separate the administration of UNIX computers based on their usage; that is production versus development. Then, the Centrify best practice OU structure as discussed in part 1 of this blog, could be manually augmented. For example, an OU called Prod and one called Dev could be created in the Computer Roles, User Roles and Computers OUs. Also, AD security groups such as cfyA_ProdAdmins and cfyA_DevAdmins could be created in the Centrify Administration OUs. These security groups can then be delegated the appropriate AD rights on the relevant OUs (see table below).

An example of the enhanced OU structure and new security groups is:

The minimum AD rights that are delegated to the security groups are:

The UNIX administrators of the development computers would be added to the group cfyA_DevAdmins and the UNIX administrators of the production computers would be added to the cfyA_ProdAdmins group.

The Centrify Zone Structure for the Enhanced Separation of Duties Model

Corresponding to the enhanced OU structure, a zone structure is created. It consists of a single parent zone named Global and two child zones named Dev and Prod. For example:

Using Centrify Access Manager, the cfyA_DevAdmins and cfyA_ProdAdmins groups are delegated full (All) control of the Dev and Prod zones, respectively. For example:

and:

Execute the mkComputerRoles.tcl script

The ComputerRoles.csv file looks like this:

Where the engcen6 computer will be joined to the Dev zone and added to the computer role DevServers.

The mkComputerRoles.tcl command to use is:

mkComputerRoles.tcl -d centrifyimage.vms -f ComputerRoles.csv -j ad,scp -a –o ou=dev,ou=computers,ou=centrify –c “ou=dev,ou=computer roles,ou=Centrify” -r “ou=dev,ou=user roles,ou=Centrify” -u tetsu

Note: The mkComputerRoles.tcl script should be executed by a user who is a member of the cfyA_CentrifyAdministrators group, which has been delegated AD rights to create objects under the Centrify OU.

Results of executing mkComputerRoles.tcl script

After executing the mkComputerRoles.tcl script the following objects are created in AD:

• The Computer Role DevServers is created in the child zone Dev. The Description field is written and an AD group, called a Computer Group (or Computer Role Group) cfyC_DevServers, is created for the Computer Role. For example, as seen in Access Manager:

• The Computer Group is created in OU=Dev,OU=Computers. For example, as seen in ADUC:

• The computer object is created in OU=Dev,OU=Computers. For example, as seen in ADUC:

• The computer object is added to the Computer Group, cfyC_DevServers. For example, as seen in ADUC:

• A Service Connection Point (SCP) object for the computer is created. For example, as seen in Access Manager:

and as seen in ADUC:

• The User Group, cfyUC_UNIX Login_DevServers, is created in OU=Dev,OU=User Roles. For example, as seen in ADUC:

• The UNIX Login role is assigned to the computer role, DevServers using the group cfyUC_UNIX Login_DevServers. For example, as seen in Access Manager:

Summary

I showed that the mkComputerRoles.tcl script can be used to create AD objects in OUs specified on the command line. Consequently, it can be used to implement a granular separation of (administrative) duties model.

Thanks for the suggestion!  I was using the stock version of SSH, after installing the Centrify-enhansed version of SSH I was able to sucessfully logon to the RHEL instance using the UPN.

Using the stock version of SSH on RHEL:

Using Kerberos authentication
Using principal username@CHILD.DOMAIN.ME
Got host ticket host/servername.child.domain.me@CHILD.DOMAIN.ME
login as username@CHILD.DOMAIN.ME

Kerberos authentication failed.  Please check
1) Unix login name is correct
2) Target service principal name is correct
3) Kerberos authentication is enabled in SSH server
4) Clock in the host is syncrhonized with the clock in AD

Using the Centrify-enhanced version of SSH

Using Kerberos authentication
Using principal username@CHILD.DOMAIN.ME
Got host ticket host/servername.child.domain.me@CHILD.DOMAIN.ME
login as username@CHILD.DOMAIN.ME
Successful Kerberos connection
S
Kernel 3.10.0-327.el7.x86_64 on an x86_64

Created home directory
[username@servername ~]$

After I uninstall this version of SSH, I can still logon using the UPN for the existing user but any other user who hasn't logged yet still gets the error.  I'm curious as to if there's anything we can do to configure the stock version of SSH to allow logon via the UPN, but unless anyone knows of a quick fix I'll just let it go.

Thanks for your help!

,

Not being an SSH expert, I believe perhaps this is a good question for Red Hat (since they support your stock version).

Note that we specialize on AD integration, Authentication and Privilege Management.  We identified early on that Microsoft's implementation of Kerberos and the design of AD is significantly different than the "traditional"LDAP/Kerberos view of the world, that's why we have added enhancements like domain to realm mapping, mechanisms to deal with Kerberos lowercase/uppercase naming, the ability to use unique samacaccountname | unix name | UPN, identity overrides, etc.

Note that commercial customers enjoy SLA-based (standard and 24x7) support for Centrify-enhanced OpenSSH Server.

Hello,

This is not necessarily a Centrify issue but we will do what we can to help.

What are the permissions on the share /home/ucftxxx?

After you try to cd to the share, run the "klist" command to confirm you're getting a service ticket.  

Any errors on the server side when trying to access the share?

Thanks,

Hi,

/home/ucftxxx is set to drwxr-xr-x

klist confirms 

API: my correct id

Principal: correct also ucftxxx@domain

issued     Expires   Principal

seems ok

Yusah

no error listed server side when I initiate mount.

Beyond making sure Kerberos is working and that Centrify is providing propert UID/GID information to both client and server, there's little we can do to help.

I next recommend you turn on debug for both the NFS client and NFS sever.

Here's an article that can help.

when I login on the server, I get

[ucftxxx@centos7-yh ~]$ /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_cdc1665164524_L7BlLa

on the Mac client klist produces this
Credential cache: API:<uid in numeric form>

Is this OK?

I have a SCR3310 reader and I was using Centrify Express and my CAC to log into work on Friday. I did the same thing Saturday and it randomly didn't work.

I followed the instructions to clean and uninstall everything. I restarted. My CAC reader LED flashes rapidly for 5 seconds then turns off. The reader is visible in System Report under USB, but the smart card is neither detected in Keychain Access nor in Centrify Smart Card Tool when I insert it into the card reader.

I figured it must be an issue with the firmware update on the SCR3310, so I tried updating the driver for SCR3310 as recommended by http://militarycac.org/elcapitan.htm . I still had the same error.

Welcome to the Express for Smart Card forum! 

Often Smart Card issues are caused by OS X not using the correct driver to detect the reader or when there are remnants of old drivers or previous versions of firmware. This can be corrected by performing cleanup and reinstall steps below.

Cleanup

1. Unplug any smart cards and readers from your Mac
2. Open the Centrify Smart Card Assistant Utility
3. Press the Uninstall button to remove any Centrify bits off the system through the standard method
4. Navigate to this folder and move or delete any remaining tokend files here:
   
   

   /System/Library/Security/tokend/    (for OS X 10.10 and below)

5. /Library/Security/tokend/           (for OS X 10.11 and above)

    

6. Use the following link to make sure you don't have any other smart card software installed that may be interfering with things: 
   http://militarycac.com/macuninstall.htm
   
   
7. Run the following command to remove any potentially cached smart card objects from the system as well:
   
   

   sudo rm -rf /var/db/TokenCache/tokens/* 

   
    

Reinstall

Note: I would recommend double-checking through all of these steps - even if you think have done them before.

1. Once your system is cleaned out. Check that your CAC reader is also updated to the latest firmware available:
   https://militarycac.com/macnotes.htm#see_the_reader
   
   
2. Download and install Express for Smart Card:
   http://www.centrify.com/express/identity-service/smart-card-download/
   
   
3. Make sure you have the DOD certificates imported into the Keychain: http://www.centrify.com/downloads/products/documentation/mac-smart-smartcard/1.0.0/wwhelp/wwhimpl/js...
   
   To use the ones that come packaged with OS X, use the steps under: 
   - "Loading DOD intermediate certificates into the keychain"
   
   To download them directly from the DOD PKI Management site, use the steps under:
   - "Downloading certificates from the DoD PKI Management site"
   
   
4. Insert your smart card into the Mac and check in Keychain Access, the card should now appear correctly in there again.
   
   
5. Try opening your target website in Safari, if it still doesn't work, check with an alternative browser and let us know how it goes.

Please create a new thread in this board if you continue to experience technical issues after performing these steps.

-Engineer801

I went through those steps exactly twice, and it still wasn't working. Should I also delete the DoD certificates that are in the "login" section of my Keychain Access? I'm assuming there must be some drivers that weren't deleted when it executed that sudo command. 

I am running OS X El Capitan 10.11.6. I have an SCR331 reader. I've installed the latest Centrify Express 5.4.2 and rebooted. I added the SystemCACertificates to my Keychain.

When I put in my PIV card the green lights go on. When I click Refresh in Centrify Express, no card shows up in the Card Status, but when I run Diagnostics, I get the following (this is the complete diagnostics output):

Smart card: CAC-XXXX-XXXX-XXXX-XXXX-XXXX

In my Keychain Access, a locked keychain with that name appears, but there is nothing in it (no certs). Loging in to my account via PIV in Safari, of course, doesn't work.

The card seems to show up as a CAC, but I'm sure it's a PIV (although I'm not really sure what the differences are -- I've been assured that the card is a PIV and I have a PIN# and I use the card at work all the time).

I've tried uninstalling and re-installing (following <http://community.centrify.com/t5/Centrify-Express/Read-Me-1st-Common-OS-X-Smart-Card-troubleshooting-steps/td-p/21904>) but same thing each time.

I appreciate any help.

-JK

Hello  and welcome to the Centrify Community!

This guide is the best place to start, as it covers most of the common issues for Mac. 

Common OS X Smart Card troubleshooting steps

Specifically, you may want to try and go to terminal and type:

     open /Library/Security/tokend

Next, in the directorty that opens,  create a new folder. (lets say "Temp")  and put the tokenD files in this new folder, all except the PIV.tokend. 

Next, try again. If this does not work, please use the url above as it includes more detailed instructions on clean up, driver updates, etc.

I hope this helps!

Have a great day!

Ryan V.