Join Log in
Score:0
akm avatar Server

Linux, Basic password authentication against 2 different AD without joining domain

mp flag
akm

We have AIX and Linux servers running with basic password authentication against a Windows AD using Kerberos, so it are local users with a username identical to their sAMAccountName in the AD and all that is done is the password check.

Both OS's use a simple krb5.conf

    [libdefaults]
        default_realm = COMPANYA.COM

    [realms]
            COMPANYA.COM {
                    kdc = ad.companya.com:88
                    admin_server = ad.companya.com:749
            }
    
    [domain_realm]
            .companya.com = COMPANYA.COM
            companya.com = COMPANYA.COM

This works fine on both OS's.

We now have the situation that there will be a company B and thus also a 2nd AD. A user will never be available on both AD's, just on either one.

So I first started on AIX as I figured this would be the hardest to get working.

Updated the krb5.conf

[libdefaults]
    default_realm = COMPANYA.COM

[realms]
        COMPANYA.COM {
                kdc = ad.companya.com:88
                admin_server = ad.companya.com:749
        }
        COMPANYB.COM {
                kdc = ad.companyb.com:88
                admin_server = ad.companyb.com:749
        }

[domain_realm]
        .companya.com = COMPANYA.COM
        companya.com = COMPANYA.COM
        .companyb.com = COMPANYB.COM
        companyb.com = COMPANYB.COM

After a bit of research it seemed all I had to do was

chuser auth_domain=COMPANYB.COM <user>

this updates the /etc/security/user file and will do the password validation against de Company B AD. So I was pleasantly surprised at how easy that was.

Next came Linux (Ubuntu boxes). Did the same krb5.conf but sadly I can not find the equivalent command for chuser under Ubuntu to point that specific user to the other AD.

What I can find is pages about using sssd and joining the realm (Linux SSSD with two AD Domains and/or https://ubuntu.com/server/docs/service-sssd-ad) but this is all more then needed (joining the realms).

what I figured out so far using tcpdump and kinit is the following:

kinit [email protected] 
<password>
kinit: KDC reply did not match expectations while getting initial credentials

kinit [email protected]
<password>
<no error>

login [email protected]
<password>
access denied

login [email protected]
<password>
access denied

Since kinit with full caps worked I had suspected the login would to, sadly it did not.

update: login [email protected] works if the user is created on the Linux box as [email protected], still not to happy with that

(forgetting the fact its not realistic to asked users to do their domain in full caps)

So long story short, how to point specific users to another AD than the default one in the krb5.conf file.

Regards,

87
1 + 0
Score:0
akm avatar Server
mp flag
akm

well I gotten a bit further the last week and this seems to work. Although I am still looking into the exact details on how PAM works.

updated/changed the /etc/pam.d/common-auth

original

auth   [success=2 default=ignore]      pam_krb5.so minimum_uid=1000
auth   [success=1 default=ignore]      pam_unix.so nullok try_first_pass

new version

auth    sufficient           pam_krb5.so minimum_uid=1000 realm=COMPANYA.COM
auth    sufficient           pam_krb5.so minimum_uid=1000 realm=COMPANYB.COM
auth    sufficient           pam_unix.so nullok try_first_pass

when logging in as a company A user it checks the AD of company A and since the user exists there the password is verified. when logging in as a company B user it checks the AD of company A, the user does not exists there and it then goes to check company B and since the user exists there the password is verified.

it's not as nice as AIX does it but it works none the less.

Regards,

+ 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.