I am trying to browse ntds.dit database file using LDAP in DSRM mode using dsamain command line utility tool as shown below:
dsamain /dbpath C:\snapshot\Windows\NTDS\ntds.dit /ldapport 5000
But it's giving me the error
The directory service failed to open a TCP port for exclusive use in DSRM mode.
One thing to note here, is that the same command with same file is working perfectly in normal mode.
What I have tried till now is:
Tried to host it on multiple ports
Tried to add all the ports in the inbound rule to allow the connection if in any case the port is blocked in DSRM mode.
Tried creating a new snapshot and mounting the same
Checked if any other process is using the same port but it was not the case and I have tried to use some many different random free ports.
But everything failed.
I am attaching the event trace below:
EVENTLOG (Warning): NTDS General / Security : 3051
The directory has been configured to not enforce per-attribute authorization during LDAP add operations. Warning events will
be logged, but no requests will be blocked.
This setting is not secure and should only be used as a temporary troubleshooting step. Please review the suggested mitigations in the link below.
For more information, please see https://go.microsoft.com/fwlink/?linkid=2174032.
EVENTLOG (Warning): NTDS General / Security : 3054
The directory has been configured to allow implicit owner privileges when initially setting or modifying the nTSecurityDescriptor
attribute during LDAP add and modify operations. Warning events will be logged, but no requests will be blocked.
This setting is not secure and should only be used as a temporary troubleshooting step. Please review the suggested mitigations in the link below.
For more information, please see https://go.microsoft.com/fwlink/?linkid=2174032.
EVENTLOG (Informational): NTDS General / Service Control : 1000
Microsoft Active Directory Domain Services startup complete
EVENTLOG (Warning): NTDS LDAP / LDAP Interface : 2509
The Directory Service failed to open a TCP port for exclusive use.
Additional Data:
Port number:
5002
Error Value:
0 The operation completed successfully.
EVENTLOG (Warning): NTDS LDAP / LDAP Interface : 2509
The Directory Service failed to open a TCP port for exclusive use.
Additional Data:
Port number:
5003
Error Value:
0 The operation completed successfully.
EVENTLOG (Warning): NTDS LDAP / LDAP Interface : 2509
The Directory Service failed to open a TCP port for exclusive use.
Additional Data:
Port number:
5002
Error Value:
0 The operation completed successfully.
EVENTLOG (Warning): NTDS LDAP / LDAP Interface : 2509
The Directory Service failed to open a TCP port for exclusive use.
Additional Data:
Port number:
5003
Error Value:
0 The operation completed successfully.
Related
We've a Windows Event Collector in DOMAIN1. DOMAIN1 and DOMAIN2 have a two-way transitive forest trust. Events from sources in D1 are forwarding fine to the WEC in D1.
D2 is setup to communicate to the same FQDN subscription manager over http/5985 (Server=http://server1.domain1.com:5985/wsman/SubscriptionManager/WEC,Refresh=60). Source initiated event collection. Port 5985 is open and listening from D2 machines through WEC in D1.
Machines in D2 are getting this in their Eventlog-ForwardingPlugin Operational logs
The forwarder is having a problem communicating with subscription manager at address http://wec1.domain1.com:5985/wsman/SubscriptionManager/WEC. Error code is 2150858909 and Error Message is <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150858909" Machine="server1.domain2.com"><f:Message>WinRM cannot process the request. The following error with errorcode 0xc0000413 occurred while using Kerberos authentication: An unknown security error occurred.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. </f:Message></f:WSManFault>.
[eventlog][1]
I don't know enough about kerberos to know if tickets from D2 can be used in D1 or somehow made to. Anyone got any ideas? I can't find much about this exact issue and WEF.
thanks
[1]: https://i.stack.imgur.com/VVF0Y.png
I have created 4 Active Directory Domain Controllers both in different locations. One is in Delhi and Another one in Mumbai.
Delhi has 2 domain controllers Primary(DDC01) and Secondary(DDC02).
Mumbai has 2 domain controllers Primary(MDC01) and Secondary(MDC02).
Both have different networks and I can take the RDP of both Domain controllers from different locations.
Now I want to connect all 4 Domain Controllers so they can replicate the data and policies.
I saw this can be done through Active Directory Site and Services.
I Added Subnet's of Both Sites in Mumbai DC i.e. MDC01
I created Sites such as Mumbai-HO and Delhi-BO in MDC01 it got replicated to MDC02.
I could see MDC01 and MDC02 but I cannot see any of the DDC01 or DDC02 showing there.
Am I missing something?
Just FYI... DDC01 and DDC02 are having different gateways due to some reason.
• Please check the active directory site replication ports are open between for communication between the Mumbai and Delhi sites by doing telnet from command prompt on each of the ports. The inbound as well as outbound communication from these to ports to each other sites should be successful. Please find the list of ports as below: -
UDP Port 88 for Kerberos authentication
UDP and TCP Port 135 for domain controllers-to-domain controller and client to domain controller operations.
TCP Port 139 and UDP 138 for File Replication Service between domain controllers.
UDP Port 389 for LDAP to handle normal queries from client computers to the domain controllers.
TCP and UDP Port 445 for File Replication Service
TCP and UDP Port 464 for Kerberos Password Change
TCP Port 3268 and 3269 for Global Catalog from client to domain controller.
TCP and UDP Port 53 for DNS from client to domain controller and domain controller to domain controller.
• Check the replication status of the AD sites through the repadmin utility by running the below command on the replicating DCs in powershell: -
‘ repadmin /syncall /force ’ or ‘ repadmin /syncall /APeD ’ or ‘ repadmin /replsum ’
If the message replied in the powershell states that ‘Syncall terminated with no errors’, then everything is fine and you need not worry about the replication status between sites. Also, you can check the replication topology status in AD Sites and subnets where all the sites are listed whether created automatically or manually as below: -
This will give out the replication status and issues relating to AD site replication. For more detailed information on the replication issues, execute the below command and check for replication issues on site level. This will give out the site wise information in csv format: -
‘ repadmin /showrepl * /csv > showrepl.csv ’
• Also, please check whether Delhi site is automatically created by KCC or not, if not, then wait for at least 24 hours after the above steps revert successful status of replication. The check the ‘Cost’ parameter of replication link in the site details workspace by clicking on it. It defines the priority level of network connection sync level between the two sites. Please find the snapshot below to know the actual cost of your network connection and set it accordingly: -
For more information on AD site replication issues, please refer the link below: -
https://learn.microsoft.com/en-GB/troubleshoot/windows-server/identity/common-active-directory-replication-errors
https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/diagnose-replication-failures
I have 2 domain controllers, one is PDC and also with Root CA(not best practice) and dns. the other one is just a domain controller.
I have done all needed configuration for ldaps in the second domain controller and tested ldp working fine from both the workstation and the DC itself. however I could not connect to it from linux server.
when using openssl s_client -connect dc02.domainname:636 -showcerts. it always returned no peer certificate available.
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1610484233
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Firewall and everything are OK since connection test are all good. I do know from where I can troubleshoot this problem as I can see certs are in computer store and service keystore.
Could someone provide me some hint as from where I can continue this troubleshooting and investigation?
Thanks.
This may depend on the permission of the cert that you are attempting to grab from the server you may want to add an everyone group and allow it to read-only or add the Linux Server to the domain via SSSD and then give the server access in the same menu. Also, ensure the cert you are attempting to push is publicly visible.
REF (How to add a Linux machine to AD): https://www.datasunrise.com/blog/professional-info/integrating-a-linux-machine-into-windows-active-directory-domain/
CA Properties
It turns out that port 88 is also needed when doing ldaps authentication and etc. when open port 88 for both tcp and udp, the test and everything works fine.
Thanks for the suggestions.
I'm trying to configure spring boot datasource as a remote IBM DB2 database. I have added the following configurations in my application.properties file:
spring.jpa.hibernate.ddl-auto=none
spring.datasource.url=jdbc:db2://<dbhost>:<dbport>/<db>
spring.datasource.username=<username>
spring.datasource.password=<password>
I even added the same properties in application.yml:
spring:
datasource:
url: jdbc:db2://dashdb-txn-sbox.services.eu-gb.bluemix.net:3000/BLUDB:sslConnection=true;
username: <username>
password: <password>
driverClassName: com.ibm.db2.jcc.DB2Driver
jpa:
properties:
hibernate:
dialect: org.hibernate.dialect.DB2Dialect
However, I'm still getting this error:
A communication error occurred during operations on the connection's underlying socket, socket input stream, or socket output stream. Error location: Reply.fill() - socketInputStream.read (-1). Message: Read timed out. ERRORCODE=-4499, SQLSTATE=08001
This question is more about configuration than programming.
See this FAQ for JDBC ERRORCODE -4499
which mentions:
(A.5) Message: Read timed out
This message is returned when client is waiting for reply from the
server and the server did not reply in time. Could be caused by client
timeout. Ensure no timeouts set in JDBC driver properties:
blockingReadConnectionTimeout=0 (default)
commandTimeout=0 (default)
loginTimeout = 0 (default)
Could also be caused by server or network issues.
If the issue is persistent, ensure you are using the latest jdbc Db2 driver ( at the present date that would be version 4.26.14 or higher).
You can use jdbc trace (follow the instructions in IBM Db2 documentation to enable jdbc trace) to look under the covers to see exactly what is happening.
Ensure the remote Db2-server has sufficient compute resources to respond in time. You may need to open a ticket with your cloud vendor (IBM) if the jdbc trace suggests a server side issue that is not under your direct control.
50001 is the usual (default) port number for ssl connections, not 3000 as you have in your question
I’m trying to connect to an LDAP directory over SSL using the Windows LDAP C-API. This fails with error code 0x51 = LDAP_SERVER_DOWN while the event log on the client computer has this:
„The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is eim-tsi2.sam.develop.beta.ads. The SSL connection request has failed. The attached data contains the server certificate.”
This is can’t be true since “Ldap Admin” is able to connect over SSL and port 636.
The LDAP directory is an Oracle DSEE which has the CA and the server certificate in the appropriate cert store.
The client has the CA installed in the “Trusted Root Certification Authorities” and there in the „Local Computer“ physical store. I assumed this to be the right place for the CA since my little client program uses the Windows LDAP C-API; LDAP Admin indeed expects the CA there.
Here is an excerpt of my program omitting the error handling and other obvious source code:
ld = ldap_sslinit(host, LDAP_SSL_PORT, 1);
// Set options: LDAP version, timeout ...
rc = ldap_set_option(ld, LDAP_OPT_SSL, LDAP_OPT_ON);
// Now connect:
rc = ldap_connect(ld, NULL);
Result:
0x51 = LDAP_SERVER_DOWN
Connecting without SSL succeeds so the LDAP server is generally accessible.
Since Ldap Admin is able to connect over SSL, I assume the certificates are valid and in the right place. But obviously the LDAP API expects them somewhere else and cannot get the server certificate from the server. I configured the certs as described here: https://msdn.microsoft.com/en-us/library/aa366105%28v=vs.85%29.aspx
What am I doing wrong?
Sometimes it helps reading error messages more carefully. The entry in the event viewer caused by an unsuccessful bind over SSL was "The server name we were expecting is eim-tsi2.sam.develop.beta.ads."
I should have noticed that the name should have been eim-tsi2.cgn.de.(etc.), instead. So the domain name part was wrong.
This is a bug in Schannel which can be solved by an entry in the registry as described here: https://support.microsoft.com/en-us/kb/2275950.
I still do not know why LDAPAdmin was able to connect without that additional registry key although it also uses the WINLDAP API and therefore should have run into the same error. But that doesn’t matter any more.
Thanks, Andrew, for your help.