Hello Robertson
Thanks for the sugestion.
I using Express version.
The AD in question has more than 10 different domains to authenticate.
I would like users to log in to their respective @domains.com.
Hello Robertson
Thanks for the sugestion.
I using Express version.
The AD in question has more than 10 different domains to authenticate.
I would like users to log in to their respective @domains.com.
As long as user's login names (samaccountname) are unique, you don't need to specify a suffix.
What I've seen are two types of strategies:
a) Map to the emai suffix (this eliminates confusion between AD UPNs and email suffixes).
b) Map to a generic suffix. E.g. user@company.sso (note that there's no need to conform to DNS's RFC1035 naming).
E.g. in some of my demo environments I use .demo (e.g.
R.P
We have the same problem in our Ubuntu 18.04 systems. Hope the new version of Centrify Express 18.9 fix this.
Hello,
we have a bunch of centos machines joined to the domain using sssd / winbind that have been working. one of these hosts is a file server. we decided add the linux desktops, all running ubuntu to the domain and had issues. this is when we found centrify, this worked in adding the machines but the UID and GIDs are different for example
two machines pulling down info for a windows group.
ubuntu
getent group domain_secure_high
domain_secure_high:x:1308624036:
centos
getent group domain_secure_high
domain_secure_high:*:79801188:
this is obviously causing a permission nightmare.. anyway to match these up? i have tried the group.ovr but that seems to only work with local groups? it did nothing for me.
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
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
This is your answer for the problem? to use MS AD???
I can't believe.
If there's a problem with CentrifyAD with SAMBA, why don't you put a msg in the download page saying that only works with Microsoft AD.
And why for some users works on one pc and on another pc with the same user doesn't work
There may be some confusion here.
We don't advertise that our software (in this case adclient, DirectControl) works with Samba acting as the Directory Service.
We QA against MS Active Directory.
We are aware of instances of people making this work, but it's not a path that we actively support (or advertise).
The only component related to Samba that we advertise is our adbindproxy, which is another Identity Mapper (instead of Windbind) that resolves identities based on our technology.
This topic is not new, if you search this forum, there are instances in which people have tried to do this, but ultimately hit some limitation.
R.P
Welcome to the Centrify forums.
This behavior is expected. The users and groups created and assigned UNIX POSIX information via SSS or Winbind have a different UID/GID numbering convention.
The passwd and group overrides (passwd.ovr, group.ovr) are premium features.
For identity consolidation, the commercial version will allow you to manipulate UNIX identity with ease using Windows GUI tools, PowerShell or *NIX-based scripting.
Note that we provide tools for migration. See this post by
R.P
Robertson,
I don't think I'm making confusion, maybe the naming of the software is confusing, because I downloaded and installed adbindproxy Express to join my Linux machines to Samba AD, and when I #adinfo -v it show adinfo (CentrifyDC 5.5.1-400), as you can see it shows CentrifyDC, but I installed adbindproxy.
ADbindproxy joined my Linux client PC to the Samba AD, and after that I can login with my domain users.
I'm not using CentrifyDC as my Active Directory Service.
As I said in my first msg, I'm having problem to login with some users in some PCs. For exemple:
user1 can login to pc1 and can't login to pc2 and user2 can't login to pc1 and can login to pc2.
I have Centrify Express (CentrifyDC 5.5.0-200) installed on several servers. On some of the servers, when I issue this command:
adquery group database_administrators
I get back the group name, its id # and members. On some of the servers, when that command is issued, I get this response instead:
database_administrators is not a zone group
All servers are running the same version (version listed above); all info from adinfo --server, --version, etc. is the same; I have done an adreload, adflush as well as left and rejoined the domain. The end result is the above "not a zone group" message.
Why does this work on some servers but not others? I am guessing something is amiss, but with the things I have looked at so far, I havent been able to determine what or where. Has anyone run into this? Any ideas on what needs updating/fixing would be appreciated.
I think this explains it.
adbindproxy is meant for organizations running Microsoft Active Directory and Centrify DirectControl that want to leverage the UID/GID schemes generated by our software for Samba-based file-services environments.
It's not meant to be used with Samba as the Directory Service.
Note that if you're a commercial customer, you don't need to rely on volunteers and this forum to get support.
R.P
Are all systems joined to the same domain?
Are all systems running the same operating system/version?
Are there any other AD-bridging integrations installed? (e.g. sssd, pb, etc?).
What happens when you do "adquery group database_administrators -A" in both systems?
I have the theory that systems are not configured equally.
R.P
Both servers are:
- The same version OS and kernel
- both are using the same DC
- both are in the same domain
- there are no AD bridging integrations
- adquery group database_administrators -A results in the members, etc being printed on the system where it works. On the other system, it says no such group.
And yes, I would agree they are not configured equally, but... one server was installed in the morning, one in the afternoon. The same package and steps were used for both... no idea where the difference might have happened.
Interesting new development...
I have been trying/looking at various things to try an determine why some groups show up and others dont. One of the things I did was to add myself to the database_administators group - which previously was NOT showing up with adquery or "getent group" commands. Now that I have updated the group (by adding myself), it is now showing up as expected - and it is the only thing I have changed.
Any ideas/insight?
Well, perhaps the object cache hadn't been refreshed and your change of group membership triggered it. There are also environmental issues like replication, communication or placement relative to a Globa Catalog. Without looking at the logs, it will be very unclear to pinpoint the issue.
Centrify's adclient contains varous caches (credential, authorization, connector, DNS, etc.) and the are commands that allow you to trigger theme (adflush and adobjectrefresh).
I'm not sure how familiar you are with the product, but there a a large number of commands that can help you:
https://community.centrify.com/t5/TechBlog/TIPS-A-Centrify-Server-Suite-Cheat-Sheet/ba-p/22568
LMK if you have additional questions.
R.P
I am familiar with that page - have been using many of those commands to try and figure out what is going on.
To add to the issue, I now have another server that WAS working and now gives the "is not a zone group" message. The only way I have found to "fix" (and it seems to be a short term fix) is to:
- adflush -f
- groups (some user in the database_administrator group)
- adquery group database_administrators (note: without doing the above groups command, this command will fail as noted above)
and then I get back the info I expect to see... but it doesnt stick around, at some random point it seems to forget about the group and the whole cycle starts over.
Per support from Centrify:
The issue you are describing is a known issue with the express version. It doesn't happen in the licensed version of the product because groups are handled differently
So I wasnt imaging things nor do I have anything misconfigured.
Hii...
I am also having this issue. Please tell me, How to fix it??? And also guide me how to do that???
Hii... Mobdro
I am also having this issue. Please tell me, How to fix it??? And also guide me how to do that???