Make CentOS 6.x an AD member of Windows IIS 2012 R2

Making a CentOS 6.x PC a domain member of an active directory is a tiresome work. I came across this painful task for several time and comes in a conclusion that atleast I will make a document which will be helpful to me in near future. On the meantime if anybody take this step for their use, I wouldn't mind.





So I will go to the task step now --

i) First of all we need some basic (latest) software for making this task possible.
They are --

1. Samba
2. Samba-client
3. Samba-winbind
4. Krb5-workstation
5. Policycoreutils-python


command for the task on console --

yum install -y ntpdate samba samba-client samba-winbind krb5-workstation policycoreutils-python

  ii) Now it's time to make the windows active directory reachable from the centos PC. For that we need to add the active directory FQDN and IP address on resolv.conf

So do it by opening file  /etc/resolv.conf and add the following --

    domain ad.local
    nameserver 192.168.0.1

if ad.local is pingable from console then our work is done for resolving AD.


 iii) Now we need to sync the time of AD and CentOS PC, so that they can authenticate in kerborus mechanism. It can be done by following --

crontab -e
Now add the following on the opening file --

 0 */4 * * * /usr/sbin/ntpdate 192.168.0.1 >/dev/null 2>&1

Now synchronize the time by --

 ntpdate 192.168.0.1
 We will see the synced time and date on console.


iv) Now we ned to edit the samba configuration file --

        [global]
    workgroup = AD
    server string = Samba Server Version %v
    security = ads
    realm = AD.LOCAL
    domain master = no
    local master = no
    preferred master = no
    socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072
    use sendfile = true
    idmap config * : backend = tdb
    idmap config * : range = 100000-299999
    idmap config AD : backend = rid
    idmap config AD : range = 10000-99999
    winbind separator = +
    winbind enum users = yes
    winbind enum groups = yes
    winbind use default domain = yeswhen I again have the same issue.
    winbind nested groups = yes
    winbind refresh tickets = yes
    template homedir = /home/%D/%U
    template shell = /bin/bash
    client use spnego = yes
    client ntlmv2 auth = yes
    encrypt passwords = yes
    restrict anonymous = 6
    log file = /var/log/samba/log.%m
    max log size = 50    


v) Edit krb5.conf file for authentication --

     [logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log
    
    [libdefaults]
    default_realm = AD.LOCAL
    ticket_lifetime = 24h
    forwardable = yes
    
    [appdefaults]
    pam = {
    debug = false
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false
    }
            [domain_realm]
           .ad.local = AD.LOCAL 
            ad.local = AD.LOCAL

vi) Now we update nss configuration file by opening file  /etc/nsswitch.conf .

    passwd: files winbind
    group: files winbind
 We are done.

vii) It's the last step to make centos an AD member of a windows system. Lets over with it by --

 net ads join -U administrator

Will ask for password. Give it and viola!!
 


 
 

 



[ffmpeg] ffmpeg-2.2 patch for relocation R_X86_64_PC32 against symbol error

ffmpeg-2.2-patch

ffmpeg-2.2 patch for relocation R_X86_64_PC32 against symbol error when compile in x64-bit


Patch Link:

Download: V1.0

Scope of Issue:

When ffmpeg is built for static library and this compiled static library is linked with another dynamic library then the final linking failed with error --

ffmpeg/libavcodec/libavcodec.a(xx_yyyy.o): relocation R_X86_64_PC32 against symbol `ff_xx_yy_zz_qq' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

Machine:

x64-bit Linux, Unix, may be windows 64-bit

How to fix:

Use the ffmpeg-2.2.patch in your FFmpeg-n2.2 release source.

How to apply patch:

  1. Copy the downloaded patch to your FFmpeg-n2.2 folder.
  2. Test the patch compatibility with your ffmpeg source by --
patch --dry-run -p1 -i  ffmpeg-2.2.patch
giving this command inside your ffmpeg source folder.
  1. If the test returns no fail patch file then you are good to patch.
  2. Now patch by following command --
patch -p1 -i ffmpeg-2.2.patch
  1. Now enjoy linking with your any other project library !!
Note: I am not in blame for any other issue and any other copyright law , if ffmpeg have any for this. This is only a remedy for the group who suffers from this compilation errors.

[eAskGitHub]Simple C++ console for all github repo release API

eAskGitHub
==========


Simple console for all github repo release API.


What?
-----

It is a c++ application with a binary. It is created to make the life simple for github repository API user. It uses curl.

Feature:
--------


1. It can receive any lenght of response from github.
2. It has it's own simple JSON parser method.
3. It is powerfull tool to know your github release download count.
4. Makefile application.

Prerequisite:
-------------


1. Need libcurl.
2. Need Centos/Linux.
3. Not tested with windows(Hopefully it will work after windows curl library installation).

Roadmap:
--------

1. Implement every API of [GitHub API](https://developer.github.com/v3/repos/releases/).

Use:
----


In console just give command -


./eAskGit

Then just follow the hints available on console or answer the querry.

Test Result:
------------


./eAskGit

Welcome to github metadata fetcher eAskGitHub v1.0 !!
It's a very simple command line app who will try to
fill your all want for github metadata(THE API).


Please enter github username: robelsharma
Please enter your one repository name: videoconference
Your querry Succeeded :)
Project Title:=>  Chat and Video call simultaneously
Creators' Login Name:=>  robelsharma
User Privilege:=>  User
Are you an Admin for this site?:=> No
Create Date:=>  2014-08-09T08:04:29Z
Publish Date:=>  2014-08-09T08:15:36Z
Project Binary:=>  VideoConference-1.0.zip
Uploader Login Name:=>  robelsharma
User Privilege:=>  User
Are you an Admin for this site?:=> No
Binary Package Type:=>  application/zip
---------------------
|Downloaded: 6 times|
---------------------
Create Date:=>  2014-08-11T05:50:48Z
Binary Package updated at:=>  2014-08-11T05:50:54Z
Download Link:=>  https://github.com/robelsharma/VideoConference/releases/download/v1.0/VideoConference-1.0.zip
*****************************************************************

Want to continue ?(y/n):n


Jabsimul with SASL Integration is a benchmarking tool for Jabber/XMPP Servers which have SASL authentication

jabsimul-with-sasl
===========

Jabsimul with SASL Integration is a benchmarking tool for Jabber/XMPP Servers which have SASL authentication.
It also has the support for *starttls*.

Special Note:
---------------------

The SASL and starttls implementation is mine. Other than this project is not mine.

Implementation:
-------------------------

I have implemented the protocol named XEP-0034: SASL Integration.

Extra Feature:
-----------------------

Other then jabsimul benchmark feature it has the extra feature of XMPP SASL authentication. I have enabled the SASL plain mechanism of authentication for xmpp login.

With that now you can have the benchmark of jabsimul with SASL authentication.


As list:

1. Implemented “XMPP TLS” from http://xmpp.org/rfcs/rfc3920.html
2. Implemented “SASL AUTH” from  http://xmpp.org/rfcs/rfc3920.html

Source code is available in here .


Procedure:
-----------------

First start a TCP connection to the XMPP server. Then convert this TCP connection to TLS with *starttls* schema request.
Then select the *SASL* auth mechanism and start the the XMPP communication with TLS. The TLS connection holds when the SASL mechanism complete a successful handshake.


1. Protocol Messaging Details with sequence -


Client:
----------

<stream:stream to="intel.com" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">

Server:
------------

<stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' id='ojTsAaoSvVKdKfmW' from='intel.com'  version='1.0'>
<stream:features>
  <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls>
  <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
    <mechanism>PLAIN</mechanism><mechanism>X-OAUTH2</mechanism>
  </mechanisms>
 
</stream:features>

Client:
-------
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>



Server:
-------
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>

Implementation details are available [here](https://developers.google.com/cloud-print/docs/rawxmpp)

How To's:
--------

cd jabsimul/jab_simul/
vi jab_simul.xml


Change *<server>jabber.localhost</server>* to your XMPP server address. Fill the xml file with you necessary configuration.

Compile it:

./configure
make

Now you can execute it:

./jab_simul

[WebRTC] Overview and analysis of webRTC media transmission and security with DTLS-SRTP Part - 1

What is webRTC?

WebRTC is an API definition being drafted by the World Wide Web Consortium to enable browser-to-browser applications for voice calling, video chat, and P2P file sharing without plugins.

In short webRTC make you independent from any messenger type application/plug-in that you need to use for a audio/video call.


Call Mechanism in WebRTC:  


Call Attributes:
  • Signaling (SIP/XMPP/Other)
  • ICE (ICE LITE rfc5245)
  • DTLS
  • SRTP
  • PCMU/OPUS for Audio
  • VP8 for Video
Signaling:

This  attribute is necessary for advertising someones' SDP or ICE-Candidate to remote buddy for a call. This can be done by many IETF standard protocol such as - SIP, XMPP or any other protocol.

ICE:

Lite ice is a must for webRTC. Because lite ice support aggressive nomination of ice candidate selection. Which enable a call more faster then any other call. Because the endpoint doesn't need to wait for all the ICE check completion before sending any media. This enables less handshake and early media technique.

DTLS:

DTLS is a transport layer security over datagram (UDP). Its' basically used for SRTP key and certificate negotiation between 2 clients. It is specified on webRTC standard that the SRTP SDES key that are transmitted over websocket is less secure then DTLS SRTP key negotiation. Because in DTLS negotiation SRTP keying material is collected in the time of negotiation and after a certificate fingerprint verification.     

In webRTC call mechanism with SDP a certain other attribute called a=fingerprint: is negotiated with SDP.

v=0
o=Mozilla-SIPUA-27.0.1 25262 1 IN IP4 0.0.0.0
s=Robel Sharma - firefox
t=0 0
a=ice-ufrag:89560a2d
a=ice-pwd:8d80078c1cb16007ee92a607c8f42006
a=fingerprint:sha-256 28:99:57:E4:CE:6F:C6:E4:A2:21:A6:9E:9C:52:EA:A3:FE:99:01:8C:68:31:8B:C3:83:16:3A:92:37:C8:5B:24
m=audio 52345 UDP/TLS/RTP/SAVPF 109 101


This finger print  attribute contain the sha-256 fingerprint value of a valid certificate. Later this value is used for verification.