Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
It has been a while since I looked at this subject, but the first thing that comes to mind is that you need to use either the KRB5 or Heimdal libraries with Kerberos. If I recall correctly, these both have the newer encryption algorithms... I think it had something to do with using HMAC-MD5...
Sorry to be so vague. Here is the link that I bookmarked from when I was working on this. Hopefully it will help you.
Hi Noway2, thanks for the link, it has a lot of good info there. Unfortunately I'm still having the same problem. The kerberos authentication method which I am using is KRB5 as it looks like its compiled into SAMBA. Interestingly enough I can query the domain using wbinfo -m, and net ads info, and even can get info from wbinfo -i <uid>. Which leads me to believe that its part of the domain but authentication seems to be broken somewhere. Were using pam modules with winbind to do the authentication and its setup exactly in same fashion as other systems. But for some reason this system is misbehaving.
Also I cant generate a ticket from kerberos using kinit command. And no tickets show up using klist.
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
kinit: KDC has no support for encryption type while getting initial credentials
I wish I could remember more of the process. Your mention of kinit reminded me of one of the things that I ran into was that I needed to use an account that had administrative privilege on the domain, in addition to the root user on the Samba machine. Here is another link I found and it is reminding me that it was at the kinit step that I had to use this account. I recall that being a magical moment when it all started to work.
I also looked at my machine and I see a file /tmp/krb5cc_0. It contains binary information, but I can see that it does contain the domain admin account that I used. Does such a file exist on your machine? I agree that wbinfo is giving you information indicates that it is partially working. Specifically, (I assume your using LDAP) it says that it is able to get the credential information from the domain controller(s). I assume you setup the /etc/krb5.conf file with your domain information, but thought I would mention that too. Remember, in windows domains are in capitals.
I wish I had that magical moment right about now but I'v looked through my configs a thousand times and cant seem to find what is wrong with them. I don't have the /tmp/krb5cc_0 but I know it exists on other systems where everything is working. That file usually gets generated when kinit command runs a successful initialization. It basically asks the kerberos for a ticket and a key session for authentication. For some strange reason I cant seem to get the ticket with the key session from kerberos as it was spitting out that error message, referencing the wrong encryption type. We also have a /etc/krb5.conf setup as well and its identical on all systems. We are trying to authenticate against Active Directory I believe it has ldap there too. And because all the config files are identical the capital sensitivity is adjusted equally across the board. Also I am using an account with domain privileges which has full rights to allow systems to join the domain. Another thing I noticed was when I logged into the domain controller and looked at the event viewer, referencing the system logs. This is what I found:
Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 26
Time: 1:35:16 PM
While processing an AS request for target service krbtgt, the account <my_uid> did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes were 16. The accounts available etypes were 23 -133 -128 3 1.
Your error message reminded me of one other thing that I ran into before it would work for me. If the configuration files are common, that allows you to rule out a lot of potential issues. One issue that wouldn't be handled by common configurations is the time sync. In order for Kerberos to work, the time synchronization between the system must be quite close, no more than 5 seconds off I think. Just to ask a stupid question, have you synchronized this system with the others against a common NTP server, such as the Domain Controller?
I just verified the clock and it looks identical from the client and domain controller perspective. So looks like ntpd is working as it should. I wonder, is there a way for me to release the client from the domain controller so when i would issue the wbinfo -m command I would see nothing. And then try to rejoin? And this way try to start from beginning? I tried the following but it doesn't seem to render the results I'm looking for:
# net ads leave -U <my_uid>@<realm>
Enter <my_uid>@<realm> password:
[2011/03/03 16:00:25.937309, 0] libads/kerberos.c:333(ads_kinit_password)
kerberos_kinit_password <my_uid>@<realm>@<realm> failed: Malformed representation of principal
Disabled account for '<server_name>' in realm '(null)'
After issuing above I looked at Active Directory and found that my <server_name> has red 'X' on it as if its disabled. But when issuing wbinfo -m I still see the domains. Also what I have noticed is that when I issue wbinfo -m command I see 3 domains as follows:
The 3rd one <realm> is the only domain I should be seeing as that is how it works on other systems. I don't know why I'm seeing 3 here. And so that's why I wondered if there is a way to go back to the initial stages when nothing was configured and then try to reconfigure the box. Is there a best way to do that do you think?
I think that the best approach to remove it would be to perform the action from the Windows side. See this link on the Microsoft Technet. As long as the machine you are working with isn't a domain controller, the process seems to be pretty straight forward. It looks like you can simply delete it from the computers and users list. You might have to try and scan for left over garbage. This appears to be more of a unclean DC removal though, and involves promotion and demotion.
I never tried the -m option on wbinfo, but I ran it and saw a similar result. In my case, I saw BUILTIN, the name of the Samba / Linux machine and a bunch of other domains that belong to the various departments.
So I engaged Dell support on the issue we were having. It looks like we got it resolved to a point where kerberos was able to generate the ticket for the client. What I did was I added a below entry into /etc/krb5.conf file under the [libdefaults] group.
allow_weak_crypto = true
That line allowed the client to generate the ticket with session key by issuing kinit command. And I was then able to view the ticket with klist command. Looks like this is only present in the RHEL 6.0. as in RHEL 5 you dont need that above entry. It might be a bug or something, not sure.
So now the new problem is getting access to the box. It keeps spitting messages into /var/log/secure file when i try to login through ssh.
sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<server_name> user=<my_uid>
sshd: Failed password for <my_uid> from <ip> port 53430 ssh2
Ok looks like I got the issue resolved. The second part involved the pam module. It looks like on redhat 5 pam is using /etc/pam.d/system-auth-ac file for authentication. In redhat 6 its using /etc/pam.d/password-auth-ac file. They switched it up a bit but the syntax is identical in both files. So my issue is now resolved. Thanks for the help and working with me on this noway2.