Kerberos 5 Tacking on Realm Twice to Principal
I recently updated a Fedora 22 workstation and SSSD logins began to fail.
Logs look good until sss_send_pac fails. Oddly the principal user is getting the domain added twice. For example:
jgiotta@magic.local@magic.local
I'm not sure what debuggin steps to take at this point. Joining the realm and performing ldapsearch commands are all successful.
Authentication is provided by an Active Directory system on a larger Windows-based network.
When I step up logging output in sssd.conf to level 10 I can review the krb5_child.log. I find the following failure in the log:
(Thu Dec 3 09:22:36 2015) [[sssd[krb5_child[2158]]]] [sss_send_pac]
(0x0040): sss_pac_make_request failed [-1][2]
(Thu Dec 3 09:22:36
2015) [[sssd[krb5_child[2158]]]] [validate_tgt] (0x0040): sss_send_pac
failed, group membership for user with principal
[jgiotta@magic.local@magic.local] might not be correct.
When this occurs I believe login fails, but terminal only says "System error" at login. At this moment, I'm essentially locked out of my profile and can only access via root.
fedora kerberos
asked Dec 2 '15 at 19:09
John Giotta
1214
add a comment |
I recently updated a Fedora 22 workstation and SSSD logins began to fail.
Logs look good until sss_send_pac fails. Oddly the principal user is getting the domain added twice. For example:
jgiotta@magic.local@magic.local
I'm not sure what debuggin steps to take at this point. Joining the realm and performing ldapsearch commands are all successful.
Authentication is provided by an Active Directory system on a larger Windows-based network.
When I step up logging output in sssd.conf to level 10 I can review the krb5_child.log. I find the following failure in the log:
(Thu Dec 3 09:22:36 2015) [[sssd[krb5_child[2158]]]] [sss_send_pac]
(0x0040): sss_pac_make_request failed [-1][2]
(Thu Dec 3 09:22:36
2015) [[sssd[krb5_child[2158]]]] [validate_tgt] (0x0040): sss_send_pac
failed, group membership for user with principal
[jgiotta@magic.local@magic.local] might not be correct.
When this occurs I believe login fails, but terminal only says "System error" at login. At this moment, I'm essentially locked out of my profile and can only access via root.
fedora kerberos
asked Dec 2 '15 at 19:09
John Giotta
1214
How exactly does sss_send_pac fail? There's an infinite number of ways for a program to fail (including making the computer explode); please describe your situation. What domain (AD, IPA, Krb5) do you have? What was done when you "patched" the system? What exact failure did you start seeing?
– grawity
Dec 3 '15 at 6:04
I assume you're seeing this in Wireshark. What "name type" is set in the request? The format you show is normal for NT-ENTERPRISE-PRINCIPAL, where the KDC (not the client) is expected to resolve various "UPN suffixes".
– grawity
Dec 3 '15 at 6:05
@grawity I've added more detail. Honestly, I don't know if that message is a warning or an error, but it's really the only log I can identify a "failure"
– John Giotta
Dec 3 '15 at 14:34
add a comment |
I recently updated a Fedora 22 workstation and SSSD logins began to fail.
Logs look good until sss_send_pac fails. Oddly the principal user is getting the domain added twice. For example:
jgiotta@magic.local@magic.local
I'm not sure what debuggin steps to take at this point. Joining the realm and performing ldapsearch commands are all successful.
Authentication is provided by an Active Directory system on a larger Windows-based network.
When I step up logging output in sssd.conf to level 10 I can review the krb5_child.log. I find the following failure in the log:
(Thu Dec 3 09:22:36 2015) [[sssd[krb5_child[2158]]]] [sss_send_pac]
(0x0040): sss_pac_make_request failed [-1][2]
(Thu Dec 3 09:22:36
2015) [[sssd[krb5_child[2158]]]] [validate_tgt] (0x0040): sss_send_pac
failed, group membership for user with principal
[jgiotta@magic.local@magic.local] might not be correct.
When this occurs I believe login fails, but terminal only says "System error" at login. At this moment, I'm essentially locked out of my profile and can only access via root.
fedora kerberos
asked Dec 2 '15 at 19:09
John Giotta
1214
I recently updated a Fedora 22 workstation and SSSD logins began to fail.
Logs look good until sss_send_pac fails. Oddly the principal user is getting the domain added twice. For example:
jgiotta@magic.local@magic.local
I'm not sure what debuggin steps to take at this point. Joining the realm and performing ldapsearch commands are all successful.
Authentication is provided by an Active Directory system on a larger Windows-based network.
When I step up logging output in sssd.conf to level 10 I can review the krb5_child.log. I find the following failure in the log:
(Thu Dec 3 09:22:36 2015) [[sssd[krb5_child[2158]]]] [sss_send_pac]
(0x0040): sss_pac_make_request failed [-1][2]
(Thu Dec 3 09:22:36
2015) [[sssd[krb5_child[2158]]]] [validate_tgt] (0x0040): sss_send_pac
failed, group membership for user with principal
[jgiotta@magic.local@magic.local] might not be correct.
When this occurs I believe login fails, but terminal only says "System error" at login. At this moment, I'm essentially locked out of my profile and can only access via root.
fedora kerberos
fedora kerberos
asked Dec 2 '15 at 19:09
John Giotta
1214
asked Dec 2 '15 at 19:09
John Giotta
1214
edited Dec 3 '15 at 14:33
asked Dec 2 '15 at 19:09
John Giotta
1214
asked Dec 2 '15 at 19:09
John Giotta
1214
asked Dec 2 '15 at 19:09
John Giotta
1214
1214
How exactly does sss_send_pac fail? There's an infinite number of ways for a program to fail (including making the computer explode); please describe your situation. What domain (AD, IPA, Krb5) do you have? What was done when you "patched" the system? What exact failure did you start seeing?
– grawity
Dec 3 '15 at 6:04
I assume you're seeing this in Wireshark. What "name type" is set in the request? The format you show is normal for NT-ENTERPRISE-PRINCIPAL, where the KDC (not the client) is expected to resolve various "UPN suffixes".
– grawity
Dec 3 '15 at 6:05
@grawity I've added more detail. Honestly, I don't know if that message is a warning or an error, but it's really the only log I can identify a "failure"
– John Giotta
Dec 3 '15 at 14:34
add a comment |
How exactly does sss_send_pac fail? There's an infinite number of ways for a program to fail (including making the computer explode); please describe your situation. What domain (AD, IPA, Krb5) do you have? What was done when you "patched" the system? What exact failure did you start seeing?
– grawity
Dec 3 '15 at 6:04
I assume you're seeing this in Wireshark. What "name type" is set in the request? The format you show is normal for NT-ENTERPRISE-PRINCIPAL, where the KDC (not the client) is expected to resolve various "UPN suffixes".
– grawity
Dec 3 '15 at 6:05
@grawity I've added more detail. Honestly, I don't know if that message is a warning or an error, but it's really the only log I can identify a "failure"
– John Giotta
Dec 3 '15 at 14:34
How exactly does sss_send_pac fail? There's an infinite number of ways for a program to fail (including making the computer explode); please describe your situation. What domain (AD, IPA, Krb5) do you have? What was done when you "patched" the system? What exact failure did you start seeing?
– grawity
Dec 3 '15 at 6:04
How exactly does sss_send_pac fail? There's an infinite number of ways for a program to fail (including making the computer explode); please describe your situation. What domain (AD, IPA, Krb5) do you have? What was done when you "patched" the system? What exact failure did you start seeing?
– grawity
Dec 3 '15 at 6:04
I assume you're seeing this in Wireshark. What "name type" is set in the request? The format you show is normal for NT-ENTERPRISE-PRINCIPAL, where the KDC (not the client) is expected to resolve various "UPN suffixes".
– grawity
Dec 3 '15 at 6:05
I assume you're seeing this in Wireshark. What "name type" is set in the request? The format you show is normal for NT-ENTERPRISE-PRINCIPAL, where the KDC (not the client) is expected to resolve various "UPN suffixes".
– grawity
Dec 3 '15 at 6:05
@grawity I've added more detail. Honestly, I don't know if that message is a warning or an error, but it's really the only log I can identify a "failure"
– John Giotta
Dec 3 '15 at 14:34
@grawity I've added more detail. Honestly, I don't know if that message is a warning or an error, but it's really the only log I can identify a "failure"
– John Giotta
Dec 3 '15 at 14:34
add a comment |
1 Answer
1
active
oldest
votes
Years late, but for the Internet searchers:
In CentOS 7 as of now (and probably for a while now, really), there is an option in sssd.conf:
use_fully_qualified_names (bool)
Use the full name and domain (as formatted by the domain's
full_name_format) as the user's login name reported to NSS.
I was struggling with the duplicated domain name in my kerberos request for xrdp and after a lot of effort learned that explicitly setting this to false even though that's the default made a difference.
sssd.conf
[domain/magic.local]
use_fully_qualified_names = false
answered Dec 6 '18 at 20:42
bgStack15
1,1791817
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1008236%2fkerberos-5-tacking-on-realm-twice-to-principal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Years late, but for the Internet searchers:
In CentOS 7 as of now (and probably for a while now, really), there is an option in sssd.conf:
use_fully_qualified_names (bool)
Use the full name and domain (as formatted by the domain's
full_name_format) as the user's login name reported to NSS.
I was struggling with the duplicated domain name in my kerberos request for xrdp and after a lot of effort learned that explicitly setting this to false even though that's the default made a difference.
sssd.conf
[domain/magic.local]
use_fully_qualified_names = false
answered Dec 6 '18 at 20:42
bgStack15
1,1791817
add a comment |
Years late, but for the Internet searchers:
In CentOS 7 as of now (and probably for a while now, really), there is an option in sssd.conf:
use_fully_qualified_names (bool)
Use the full name and domain (as formatted by the domain's
full_name_format) as the user's login name reported to NSS.
I was struggling with the duplicated domain name in my kerberos request for xrdp and after a lot of effort learned that explicitly setting this to false even though that's the default made a difference.
sssd.conf
[domain/magic.local]
use_fully_qualified_names = false
answered Dec 6 '18 at 20:42
bgStack15
1,1791817
add a comment |
Years late, but for the Internet searchers:
In CentOS 7 as of now (and probably for a while now, really), there is an option in sssd.conf:
use_fully_qualified_names (bool)
Use the full name and domain (as formatted by the domain's
full_name_format) as the user's login name reported to NSS.
I was struggling with the duplicated domain name in my kerberos request for xrdp and after a lot of effort learned that explicitly setting this to false even though that's the default made a difference.
sssd.conf
[domain/magic.local]
use_fully_qualified_names = false
answered Dec 6 '18 at 20:42
bgStack15
1,1791817
Years late, but for the Internet searchers:
In CentOS 7 as of now (and probably for a while now, really), there is an option in sssd.conf:
use_fully_qualified_names (bool)
Use the full name and domain (as formatted by the domain's
full_name_format) as the user's login name reported to NSS.
I was struggling with the duplicated domain name in my kerberos request for xrdp and after a lot of effort learned that explicitly setting this to false even though that's the default made a difference.
sssd.conf
[domain/magic.local]
use_fully_qualified_names = false
answered Dec 6 '18 at 20:42
bgStack15
1,1791817
answered Dec 6 '18 at 20:42
bgStack15
1,1791817
answered Dec 6 '18 at 20:42
bgStack15
1,1791817
answered Dec 6 '18 at 20:42
bgStack15
1,1791817
1,1791817
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1008236%2fkerberos-5-tacking-on-realm-twice-to-principal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
How exactly does sss_send_pac fail? There's an infinite number of ways for a program to fail (including making the computer explode); please describe your situation. What domain (AD, IPA, Krb5) do you have? What was done when you "patched" the system? What exact failure did you start seeing?
– grawity
Dec 3 '15 at 6:04
I assume you're seeing this in Wireshark. What "name type" is set in the request? The format you show is normal for NT-ENTERPRISE-PRINCIPAL, where the KDC (not the client) is expected to resolve various "UPN suffixes".
– grawity
Dec 3 '15 at 6:05
@grawity I've added more detail. Honestly, I don't know if that message is a warning or an error, but it's really the only log I can identify a "failure"
– John Giotta
Dec 3 '15 at 14:34