GSSAPI authentication works on one machine, but not on three (almost) exact clones

Showing results for 
Search instead for 
Do you mean 
Reply
Participant II
Posts: 2
Registered: ‎10-04-2016
#1 of 4 245

GSSAPI authentication works on one machine, but not on three (almost) exact clones

I have four machines running Centrify Express (DC 5.5.1, stock SSH under updated CentOS 7). One machine was properly installed, configured adn added to the domain and autozone, the other three are clones in which the hostnames  and IPs were changed after which they were a(re)dded to the domain and autozone. The original machines nicely uses SSO through GSSAPI. The other three keep asking for a password. As said, ssh_config and sshd_config are identical.  Any pointers on how to troubleshoot this?

Centrify Guru I
Posts: 2,433
Registered: ‎07-26-2012
#2 of 4 240

Re: GSSAPI authentication works on one machine, but not on three (almost) exact clones

[ Edited ]

@DiederickS,

 

Welcome to the community.

 

Please make sure that when you make clones, you run the "sudo adleave --remove" command prior to creating the clone.  Otherwise there is unique machine information tatooed in the system.

 

Please do this, then join each machine individually (the original and the clones) with different names, IPs and report back your results.

 

There's no use to start troubleshooting this without making sure that the cloning process was integral.

 

Note for future readers:  The same way a Window system has to be sysprepped before cloning it, an AD-joined, Centrify system has to be reset to just having the normal bits in place without any "unique machine join info" tied to the box.  Otherwise strange things will happen.

Alternatively, you can use a DevOps solution to have the system pull the Centrify bits, customize and automate the join.  We can do this with full-fledged OSs and with containers.  There are several articles in the TechBlog section that outline how to do this in your environment, in clouds like AWS, etc.

 

R.P

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Participant II
Posts: 2
Registered: ‎10-04-2016
#3 of 4 234

Re: GSSAPI authentication works on one machine, but not on three (almost) exact clones

I am afraid the results after adleave -remove and adjoin remain the same. Is there some way to properly purge all information?
Highlighted
Centrify Guru I
Posts: 2,433
Registered: ‎07-26-2012
#4 of 4 230

Re: GSSAPI authentication works on one machine, but not on three (almost) exact clones

[ Edited ]

I am assuming that you:

a) identified your master (template machine)

b) ran adleave -- remove (effectively leaving the domain)

b) cloned the systems

c) re-joined the original machine

d) renamed and re-ip'd all systems (renaming rules are different per Linux or UNIX version/distro)

e) ran the adjoin command again on all new clones.

 

If that's the case, we are also assuming:

1. That you're not trying to connect to these systems by IP, but by FQDN.

2. That the FQDNs are resolvable.

3. That the machine objects in AD are tied to their corresponding FQDN and that the service principal names (SPNs) are registered as expected.
Tip:  to see the system SPNs, run the elevated adinfo -C command.  E.g.
adinfo-c.PNG

4. That the client system you're initiating the connection from and the user are joined to the same domain and that the user has a Kerberos TGT.

5. That the client software (e.g. PuTTY) is configured to attempt a GSSAPI connection.

 

This would be much easier if you had started with an error message, description or screenshot.

 

R.P

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