We have mostly Linux users who login via Kerberos. But we also have a few (<50) users who use both Linux and Windows. This is supposed to grow in the future.
We would like to keep our User database on the Unix/Kerberos side.
But for some reason that eludes me I can not get it to work yet.
I did the following after reading some guides (domains anonymized):
1) Add the ADDC to /etc/krb5.conf on the linux KDC and Linux hosts
AD.DOMAIN = {
kdc = PDC.AD.DOMAIN
admin_server = PDC.AD.DOMAIN
default_domain = ad.domain
}
2) Add cross realm principals on the Linux side
addprinc -pw <longPW> -requires_preauth krbtgt#AD.DOMAIN
addprinc -pw <longPW> -requires_preauth krbtgt/LINUX.REALM#AD.DOMAIN
addprinc -pw <longPW> -requires_preauth krbtgt/AD.DOMAIN#LINUX.REALM
3) Add realm info via ksetup to Windows ADDC and other Windows machines
ksetup
default realm = ad.domain (NT Domain)
LINUX.REALM:
kdc = kdc.linux.realm
kpasswd = kdc.linux.realm
Realm Flags = 0x0No Realm Flags
Mapping all users (*) to a local account by the same name (*).
4) Add Two-Way trust on Windows side via
netdom trust /d:LINUX.REALM ad /add /PT:longPW /realm /twoway
Check returns
nltest /TRUSTED_DOMAINS
List of domain trusts:
0: LINUX.REALM (MIT) (Direct Outbound) (Direct Inbound) ( Attr: non-trans )
1: AD ad.domain (NT 5) (Forest Tree Root) (Primary Domain) (Native)
The command completed successfully
But also
netdom trust lst /d:LINUX.REALM /verify /KERBEROS /twoway
The command failed to complete successfully.
5) Add mapping to users
altSecurityIdentities for user ad\test shows kerberos: test#LINUX.REALM
I can login with ad\test (which is not what I want) but I can not log in as test#LINUX.REALM which is what I wanted
On the other hand:
kinit test#AD.DOMAIN
Password for test#AD.DOMAIN:
root#kdc:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: test#AD.DOMAIN
Valid starting Expires Service principal
21/07/2017 13:24 21/07/2017 23:24 krbtgt/AD.DOMAIN#AD.DOMAIN
renew until 22/07/2017 13:24
My problem:
I cannot login on the windows side with principals test#LINUX.REALM. As written in the topic we want the Linux Realm to be the account domain, not the AD, which should be possible as well, shouldn't it? We only want to have to handle account creation, deletion etc. in the Linux Realm, having the Windows Users log in with their Linux Account/Password.
What am I missing?
Doing
ksetup /addhosttorealmmap .dns.domain LINUX.REALM
on each windows client mostly fixed this problem.
I can now login with user#LINUX.REALM to the windows client with correct mapping.
Related
Have a fairly simple setup of one AD server with various linux hosts. We attached the linux hosts to our domain by using:
realm discover domain.example.com
realm join domain.example.com -U user.adm
Our /etc/sssd/sssd.conf looks like:
[sssd]
domains = domain.example.com
config_file_version = 2
services = nss, pam
[domain/domain.example.com]
ad_domain = domain.example.com
krb5_realm = DOMAIN.EXAMPLE.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = false
fallback_homedir = /home/%u#%d
access_provider = simple
simple_allow_groups = linuxaccess#domain.example.com
From here we can login as AD users that are a part of the linuxaccess group. I attempted to reset a password but get:
[username.lin#hostname ~] passwd
Current Password:
New password:
Retype new password:
Password change failed. Server message: Access denied
passwd: Authentication token manipulation error
/var/log/secure shows:
Oct 12 14:39:48 computer passwd: pam_unix(passwd:chauthtok): user "username.lin" does not exist in /etc/passwd
Oct 12 14:40:01 computer passwd: pam_unix(passwd:chauthtok): user "username.lin" does not exist in /etc/passwd
Oct 12 14:40:01 computer passwd: pam_sss(passwd:chauthtok): Password change failed for user username.lin: 20 (Authentication token manipulation error)
Thoughts on why changing passwords do not appear to be supported or what the misconfiguration could be? Guessing something in pam.d but not confident.
I tried to reproduce your scenario and I am also getting the same error when attempting password change for AD users.
the default group policy has a "Minimum Password Age" which will prevent you from changing the password for 24 hours after user creation / previous password change.
Solution is to change the GPO to zero days and do a gpupdate on domain controller - or wait for 24 hours.
The GPO security settings on your Active Directory server were most likely default or possibly customized by the AD Administrator.
Note: Minimum password age:
Set this value to 1 day. Microsoft recommends to not set this to 0, because it would allow immediate password changes. Users can change the password 24 times the same day and get back to the old password.
Reference: https://www.pcwdld.com/domain-password-policy-how-to-configure#wbounce-modal
can't change AD password on ubuntu with sssd
I am attempting to translate "local login names" to a specific Kerberos principal name. On the Kerberos server, principals for the users are stored in the format of:
<username>/<group>#<REALM>.
For example, I would like the login name testUser1 to be translated to the principal name: testUser1/Admins#HOME.COM
The reason I would like to use this format is so that I can enforce Kerberos access control for users part of specific groups via the kadm5.acl file. Only users within the Admins group should be authorized to create Kerberos principals.
The system is comprised of 3 separate servers: KRB-Server (krb-server.home.com), SSH-Server (ssh-server.home.com), and LDAP-Server (ldap-server.home.com). All servers are running Ubuntu 16.04. The KRB-Server is running KRB5 1.16-2 from the zodops/ubuntu-backports repository. The SSH-Server is using SSSD to enable authentication/authorization using the Kerberos authentication server and the LDAP identity/authorization server.
I have attempted to perform local user name to Kerberos principal mappings using rules defined in the auth_to_local option.
RULE:[2:$1/$2#$0](.*\/Admins#HOME\.COM)s/\/Admins#HOME\.COM//
From what I understand the first section of the rule:
[2:$1/$2#$0]
Will match the kerberos principals with two components and translate it to the format <first component>/<second component>#<realm>
The next section (.*/Admins#HOME.COM) will match the result of the first section and proceed to the third and final replacement expression section which will remove the second component and realm from the principal name.
s/\/Admins#HOME\.COM//
This should translate the Kerberos principal name "testUser1/Admins#HOME.COM" to the local login name "testUser1". However, this configuration does not appear to be taking effect.
The configuration files are as follows:
/etc/krb5.conf on krb-server.home.com
[libdefaults]
default_realm = HOME.COM
[realms]
HOME.COM = {
kdc = krb-server.home.com
admin_server = krb-server.home.com
master_kdc = krb-server.home.com
default_domain = home.com
database_module = openldap_ldapconf
auth_to_local = RULE:[2:$1/$2#$0](.*\/Admins#HOME\.COM)s/\/Admins#HOME\.COM//
auth_to_local = DEFAULT
}
[domain_realm]
.home.com = HOME.COM
[dbdefaults]
ldap_kerberos_container_dn = cn=krb5,dc=home,dc=com
[dbmodules]
openldap_ldapconf = {
db_library = kldap
ldap_kdc_sasl_mech = EXTERNAL
ldap_kadmind_sasl_mech = EXTERNAL
ldap_servers = ldaps://ldap-server.home.com
ldap_conns_per_server = 5
}
[logging]
admin_server = FILE:/var/log/krb-admin-server.log
kdc = FILE:/var/log/kdc.log
default = FILE:/var/log/default-kdc.log
/etc/krb5.conf on ssh-server.home.com
[libdefaults]
default_realm = HOME.COM
[realms]
HOME.COM = {
kdc = krb-server.home.com
admin_server = krb-server.home.com
master_kdc = krb-server.home.com
default_domain = home.com
auth_to_local = RULE:[2:$1/$2#$0](.*\/Admins#HOME\.COM)s/\/Admins#HOME\.COM//
auth_to_local = DEFAULT
}
[domain_realm]
.home.com = HOME.COM
When attempting to authenticate on the SSH-Server via ssh testUser1#localhost or su -- testUser1, an error is thrown in the Kerberos KDC log file.
CLIENT_NOT_FOUND: testUser1#HOME.COM for krbtgt/HOME.COM#HOME.COM, Client not found in Kerberos database
When I attempt to authenticate to a principal with a single component (testUser1#HOME.COM), the authentication works flawlessly. Unfortunately, I am unable to authenticate to two component principal names as stated above.
Are my assumptions on the auth_to_local configuration option correct? If so, can anybody shine some light on how to get this configuration to work? If not, what other solutions can I use for this problem?
I was able to solve this problem through the use of the SSSD option, ldap_user_principal.
I defined a new attribute and objectclass to the LDAP database which will hold the target principal name. I then added the new objectclass (krbHelper) and attribute (principalName) to the LDAP entry holding user information.
dn: uid=testUser1,ou=People,dc=home,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: krbHelper
uid: testUser1
-
-
principalName: testUser1/Admins#HOME.COM
-
Inside the sssd.conf file, I then set the value of the option ldap_user_principal to the new attribute.
ldap_user_principal = principalName
I am now able to login via SSH with principals containing more then two components.
Another potential solution would be to define aliases for the principal LDAP entries using krbCanonicalName and additional krbPrincipalName attributes as outlined in the end of this documentation (https://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_ldap.html). The SSSD option krb5_canonicalize would then be set to true to canonicalize the login principal name.
Testing with kinit -C allowed me to successfully perform a initial ticket request for two component principal names. However I was unable to test this with SSSD as the krb5_canonicalize option in unavailable in the SSSD version I am using.
I have Luna SA hsm and windows server 2012r2 + IIS, I'd like to lunch site using https, I'm performed standard connection operations between LunaSA HSM and win2012r2. Then I generated certification request (key pair in HSM), after that i recieved certificate from certification center and performed "certreq -accept somecert.cer"
Next, I'm configured IIS for some site, and when i selecting required certificate, i recieving this problem:
Please advise what can i do in this situation.
My trouble was in Luna KSP configuration
I registered slot for:
User: Administrator / Domain: INTEGRATION2;
User: Administrator / Domain: NT_AUTHORITY;
but second string is wrong, it must be:
User: SYSTEM / Domain: NT_AUTHORITY;
I am trying to setup a local database in a windows 10 computer, and grant access to my local windows-user. But when I try to access the database through my node-application I get the following error-message: error: password authentication failed for user "windowsuser" using the following db-url: postgres://localhost:5432/testdb
I am using the module "pg" to connect to the database, and everything works when I specify a username and password in the URL - but I want to connect using my windows credentials.
I have setup a superuser with the same name as my windowsuser:
CREATE ROLE windowsuser LOGIN
SUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION;
And setup a database windowsuser as owner:
CREATE DATABASE testdb
WITH OWNER = windowsuser
ENCODING = 'UTF8'
TABLESPACE = pg_default
LC_COLLATE = ''
LC_CTYPE = ''
CONNECTION LIMIT = -1;
GRANT ALL ON DATABASE testdb TO windowsuser;
The windows user has no password, and I want to be able to just login with the current system user. Am I missing something essential here to get proper access?
I believe you cannot simply authenticate without a password. Have a look at the PostgreSQL doc here:
PostgreSQL: Documentation: 9.4: Authentication Methods
You will need to setup "Trust Authentication" instead of "Password Authentication".
19.3.2. Password Authentication
"PostgreSQL database passwords are separate from operating system user passwords. The password for each database user is stored in the pg_authid system catalog. Passwords can be managed with the SQL commands CREATE USER and ALTER ROLE, e.g., CREATE USER foo WITH PASSWORD 'secret'. If no password has been set up for a user, the stored password is null and password authentication will always fail for that user."
Is there a specific reason why you are opting to use a Windows system account, as well as no password?
i want to validate a set of credentials against the domain controller. e.g.:
Username: joel
Password: splotchy
Domain: STACKOVERFLOW
In .NET 3.5 and newer you can use PrincipalContext.ValidateCredentials(username, password).
Otherwise you're in trouble.
Following the code in the Microsoft Knowledge Base article How to validate user credentials on Microsoft operating systems, i get to the point where you call AcceptSecurityContext:
ss = AcceptSecurityContext(
#pAS._hcred, //[in]CredHandle structure
phContext, //[in,out]CtxtHandle structure
#InBuffDesc, //[in]SecBufferDesc structure
0, //[in]context requirement flags
SECURITY_NATIVE_DREP, //[in]target data representation
#pAS._hctxt, //[in,out]CtxtHandle strcture
#OutBuffDesc, //[in,out]SecBufferDesc structure
ContextAttributes, //[out]Context attribute flags
#Lifetime); //[out]Timestamp struture
except that the function fails with:
SEC_E_NO_AUTHENTICATING_AUTHORITY (0x80090311)
The function failed. No authority could be contacted for authentication. This could be due to the following conditions:
The domain name of the authenticating party is incorrect.
The domain is unavailable.
The trust relationship has failed.
This would be a useful error, except that i can validate the same credentials from .NET 3.5 using:
using (PrincipalContext context = new PrincipalContext(ContextType.Domain, domain))
{
valid = context.ValidateCredentials(username, password);
}
What could be happening that allows .NET to validate a set of credentials, while native code cannot?
Update: LogonUser also fails:
LogonUser("joel#stackoverflow.com", null, "splotchy",
LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_WINNT50, out token);
with
1311 - There are currently no logon servers available to service the logon request
Update Two: i've tried both the preferred Negotiate provider, as well as the Windows NT4 legacy "NTLM" provider
String package = "Negotiate"; //"NTLM"
QuerySecurityPackageInfo(package, [out] packageInfo);
...
AcquireCredentialsHandle(
null, //[in] principle
package, //[in] package
SECPKG_CRED_OUTBOUND, //[in] credential use
null, //[in] LogonID
pAuthIdentity, //[in] authData
null, //[in] GetKeyFn, not used and should be null
null, //[in] GetKeyArgument, not used and should be null
credHandle, //[out] CredHandle structure
expires); //[out] expiration TimeStamp structure
I presume that this is to solve the same problem as another question that you posted.
I kind of understand what you are trying to do now. Let me recap what you wrote on another post.
Username Password Domain Machine on domain? Validate as
======== ======== ================= ================== ==============
iboyd pass1 . No Local account
iboyd pass1 (empty) No Local account
iboyd pass1 stackoverflow.com No Domain account
iboyd pass1 . Yes Local account
iboyd pass1 (empty) Yes Domain account
iboyd pass1 stackoverflow.com Yes Domain account
You want to
Authenticate a user from a domain that your machine doesn't trust
Authenticate a user from a domain that your machine trusted
Authenticate a local user
You can achieve the first two cases by doing proper SSPI handshaking with the domain controller. The KB article that you are referring to in another question is doing loop back SSPI handshaking. It's not going to work in case number one because the client machine does not trust the domain that you are authenticating to. That should be why you are seeing SEC_E_NO_AUTHENTICATING_AUTHORITY.
To cut it short, if you want to do exactly the same thing as
PrincipalContext.ValidateCredentials(username, password);
you need to handle the local user differently from the domain user. For domain user, you need to call ldap_bind_s to bind to the domain controller using the given credentials. For local user, you need to use ADsOpenObject to bind to the WinnT://YourComputerName using the given credentials. This is what PrincipalContext.ValidateCredentials doing from what I read in the Reflector.
I don't see there is any equivalent one single native API doing the same thing for you.